Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Extremely Linear Git History

westling.dev

Post reply on HN
Print view View original

71–80 of 366 posts

Re: Extremely Linear Git History

#71

Post by danwee »

larschdk wrote: post #49

I 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…

I usually do `git merge --no-ff development` when working on my feature branch. We do not leave feature branches "open/live" for too much time, so merge conflicts are not usually a problem, but sometimes they do happen.

I like cherry-pick, but I barely use it (e.g., I need to cherry-pick one commit from branch X into my branch). I don't like rebase much because it requires force-push.

Re: Extremely Linear Git History

#72

Post by zegl »

chrismorgan wrote: post #69

The article talks about eight -character prefixes later in the article, but Git short refs actually use seven -character prefixes when there is no collision on that (and that’s what’s shown earlier in the article). So you can divide time by 16. For me on a Ryzen 5800HS laptop, lucky_commit generally takes 11–12 seconds. I’m fine with spending that much per commit when publishing. The three minutes eight-character pre…

I left some details out of the post to make it shorter.

What I’m actually is doing is generating a 7-digit incremental number followed by a fixed 0. Some UIs show 7 characters and some show 8, this felt like a nice compromise. Plus it’s easier to distinguish between the prefix and the suffix when looking at the full SHA when they are always separated by a 0.

Re: Extremely Linear Git History

#73

Post by nextlevelwizard »

larschdk wrote: post #49

I 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…

If you have bunch of commits in a feature that are related it is easier to revert merges (even if you do pre-merge rebase from master and then merge with --no-ff)

Re: Extremely Linear Git History

#74

Post by oneeyedpigeon »

whoooooo123 wrote: post #53
oneeyedpigeon wrote: post #43

Earlier quoted context omitted.

Using whitespace is cool, but you know what would be really cool? Using a thesaurus to reword the commit message until it matches the hash :)

Only works if your commit message is written in hexadecimal characters

I don't understand — the example in the article adds the string "magic: MTQIpN2AmwQA" to the commit message. The final hash is hexadecimal, but what you feed into it isn't.

Re: Extremely Linear Git History

#75

Post by mikehotel »

kreetx wrote: post #33
mgsk wrote: post #22

Earlier quoted context omitted.

Or maybe it is _extremely_ tidy.

I think the question boils down to "where is the junk?" ;) I.e, there is always junk, some put it in a commit hash, others into the files committed.

And now this uses invisible junk (white space). See update: https://news.ycombinator.com/item?id=33704810

Re: Extremely Linear Git History

#76

Post by jrmg »

chrismorgan wrote: post #52

It has been my habit for a while to make the root commit 0000000 because it’s fun, but for some reason it had not occurred to me to generalise this to subsequent commits. Tempting, very tempting. I have a couple of solo-developed-and-publicly-shared projects in mind that I will probably do this for.

How do you make the first commit 0000000? (Without using this project, obviously).

Re: Extremely Linear Git History

#77

Post by wirrbel »

I 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 at diffs, or emacs.

Of course it’s neat to have GitHub actions now and pull-requests for asynchronous code review. But I learned so much from my colleagues directly in that nowadays obscure working mode which I am still grateful for.

Re: Extremely Linear Git History

#78

Post by rjmunro »

larschdk wrote: post #49

I 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…

I usually rebase the branch onto the upstream branch (master or main or whatever) if there are merge conflicts. You can then resolve the conflicts commit by commit. This requires force pushes, but they are are not normally a problem because only one dev tends to work on a particular branch before it's merged.

If you do have multiple devs working on the same branch, use `git pull --rebase` to stay in sync with each other, don't use merges and leave lots of merge commits. If you need to resolve conflicts with upstream, make sure other people have stopped working on the branch, rebase it, then merge.

Post reply on HN