Sounds great for a single person project but perhaps a simpler VCS was better then?
Extremely Linear Git History
161–170 of 366 posts
Re: Extremely Linear Git History
#162Very good!
I use this hack every day in winter to heat my apartment (charging laptop at work, run git brute force at home).
Re: Extremely Linear Git History
#163A neat trick with this tool is to generate a commit message that corresponds to a given issue number. It could almost be useful.
Kudos to @zegl for this cool project.
Re: Extremely Linear Git History
#164this is a joke right?
Re: Extremely Linear Git History
#165[deleted]
Re: Extremely Linear Git History
#166“
So we only have one option: testing many combinations of junk data until we can find one that passes our criteria.
“
I have a somewhat related interest of trying to find sentences that have low Sha256 sums.
I made a go client that searches for low hash sentences and uploads winners to a scoreboard I put up at https://lowhash.com
I am not knowledgeable about gpu methods or crypto mining in general, I just tried to optimize a cpu based method. Someone who knows what they are doing could quickly beat out all the sentences there.
Re: Extremely Linear Git History
#167I think the sweet spot in Developer productivity was when we had SVN repos and used git-svn on the client. Commits were all rebased on git level prior to pushing. If you committed something that broke unit tests your colleagues would pass you a really ugly plush animal of shame that would sit on your desk until the next coworker broke the build. We performed code review with a projector in our office jointly looking…
I have my old team's rubber chicken and I'm never giving it up.
In-person code review is the only way to do it. Pull requests optimize for the wrong part of code review, so now everyone thinks it's supposed to be a quality gate.
Re: Extremely Linear Git History
#168I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…
Personally, I believe merging 'master' to your feature branch is the wrong model... what one should do is create a new branch from master and merge the old branch into it.
Why? Merging master into the feature branch is done so that you can test the conflict resolution in the branch before inflicting it on everyone. It’s also done on a regular basis in longer running feature branches to prevent large conflicts from accumulating- you can merge master into your branch multiple times to stay current with master before ever merging back into master. I’m not sure why parent says this causes them to lose track of which changes happened in which branch. The history does get a bit more complex at a glance, but for any given commit, it’s easy to pinpoint their origin if using only merge commits. It only gets harder if you accidentally rebase someone else’s commits along the way. For smaller feature branches and smaller projects, it’s okay to merge branches into master, but for large branches, large projects, large teams, and teams that care about testing, merging master into feature branches is a best practice. What makes you consider it ‘wrong’?
Re: Extremely Linear Git History
#169Gitlab supports an option called "Fast-forward merge":
> No merge commits are created.
> Fast-forward merges only.
> When there is a merge conflict, the user is given the option to rebase.
The maintainer can enable this for a project.
Re: Extremely Linear Git History
#170Is it possible to change the checksum implementation that git uses, through configuration or a plugin? I find all this hash inverting quite inelegant.
There's an effort to add support for sha256, but it's... not recommended https://lwn.net/Articles/898522/