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

101–110 of 366 posts

Re: Extremely Linear Git History

#101

Post by bsza »

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…

> you might as well rebase or cherry-pick

Both tools are pure vandalism compared to merge. Among the two, cherry-picking is preferable in this case because you're "only" destroying your own history, so in the end, it's your funeral.

> Developer end up fixing additional issues in the merge commit instead of actual commits.

A merge commit IS an actual commit, in every sense of the word. The notion it somehow isn't, is what you need to get rid of.

Re: Extremely Linear Git History

#102

Post by semiquaver »

simiones wrote: post #83
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…

Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your…

As sibling mentioned, this is totally solved by git-rerere.

Re: Extremely Linear Git History

#103

Post by avar »

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…

Git hasn't used "seven-character prefixes when there are no collisions" in a long time.

It's a combination of the "repo size" (as in, estimated number of objects) and a hard floor of seven characters.

You can see this by running "git log --oneline=7" on any non-trivially sized repository (e.g. linux.git). There's plenty of hashes that uniquely abbreviate to 7 characters, but they're currently all shown with 12 by default.

Re: Extremely Linear Git History

#104

Post by booleandilemma »

semiquaver wrote: post #102
simiones wrote: post #83

Earlier quoted context omitted.

Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your…

As sibling mentioned, this is totally solved by git-rerere.

When can we move to Sapling again?

Re: Extremely Linear Git History

#105

Post by zegl »

kretaceous wrote: post #37
zegl wrote: post #36

Earlier quoted context omitted.

Update: git-linearize now uses lucky_commit as it's backend!

I haven't checked your codebase so I don't know how easy it was but damn, you replaced your backend within 16 minutes according to your comment timings. That's some nice modularization. Good job!

You're giving me too much credit. The script [1] is only 50 lines of bash.

[1]: https://github.com/zegl/extremely-linear/blob/0011003da13132...

Re: Extremely Linear Git History

#106

Post by ncann »

broeng wrote: post #91
simiones wrote: post #83

Earlier quoted context omitted.

Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your…

In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine. It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.

Yeah that scenario only ever happens if you have an extremely large branch that hasn't been merged into the target branch for a long time (like a feature branch that takes months to develop), which btw isn't really something that should be done anyway (always try for more frequent merge with small side branches).

Re: Extremely Linear Git History

#108

Post by titzer »

wirrbel wrote: post #77

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…

Commit queues are so far superior to shaming broken builds that I think it's only nostalgia that makes you miss it.

Re: Extremely Linear Git History

#109

Post by BiteCode_dev »

semiquaver wrote: post #102
simiones wrote: post #83

Earlier quoted context omitted.

Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your…

As sibling mentioned, this is totally solved by git-rerere.

Partially. Unfortunatly, rerere is not perfect, and will only solve 80% of the cases.

For big rebase, this can add up to a lot, which I just paid the price last week.

Re: Extremely Linear Git History

#110

Post by flir »

wirrbel wrote: post #77

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…

Two years from peak Covid, and the plushies are the object of nostalgia.
Post reply on HN