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

91–100 of 366 posts

Re: Extremely Linear Git History

#91

Post by broeng »

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…

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.

Re: Extremely Linear Git History

#92

Post by sshine »

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…

> 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 did have an ugly plush animal, but it served more obscure purposes. For blame of broken builds, we had an info screen that counted the number of times a build had passed, and displayed below the name of the person who last broke it.

Explaining to outsiders and non-developers that "Yes, when you make a mistake in this department, we put the person's name on the wall and don't take it down until someone else makes a mistake" sounds so toxic. But it strangely enough wasn't so harsh. Of course there was some stigma that you'd want to avoid, but not to a degree of feeling prolonged shame.

Re: Extremely Linear Git History

#93

Post by adgjlsfhk1 »

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…

you can often solve this by squashing before rebasing.

Re: Extremely Linear Git History

#94

Post by gyulai »

breck wrote: post #85
gyulai wrote: post #67

Earlier quoted context omitted.

Basically, not to put too fine a point on it, I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future. I mean: Imagine going back in time 20 years to when git, hg, and bzr were created and telling the creators of those tools: "Hey, while designing your technology, you should be aware that it'll end up being used as a worldwide centralized monorepo r…

Oh we use distributed day in and day out for everything. Once you start battling censorship you’ll get it.

...so you are among the 1% who use the functionality that causes 99% of what makes git's mental model so convoluted and hard to learn (for everyone, not just the one-percenters).

Re: Extremely Linear Git History

#95

Post by quadhome »

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…

man git-rerere

Re: Extremely Linear Git History

#96

Post by YetAnotherNick »

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…

You should do reverse rebase(if it makes sense lol) for this. Instead of rebasing branch to master, rebase master to branch. The only downside is that it requires many force push in the branch.

Re: Extremely Linear Git History

#97

Post by tazjin »

bcoughlan wrote: post #35

I wish Git had more support for "linear" revisions in the main branches. It's great for continuous delivery where you can get a unique identifier that's also human-friendly. I emulate this by counting the number of merges on main: git rev-list --count --first-parent HEAD But it's not that traceable (hard to go from a rev back to a commit).

We do this at TVL, and push the corresponding revision as a ref (refs/r/$n) back to git. See for example our cgit log view: https://code.tvl.fyi/log/

This way, a correctly configured git client (which pulls those refs) can use `git checkout r/1234` to get to that revision. It's also noteworthy that this is effectively stateless, so you can reproduce the exact revisions locally with a single shell command without fetching them from the remote.

The revisions themselves are populated in CI: https://cs.tvl.fyi/depot@c537cc6fcee5f5cde4b0e6f8c5d6dcd5d8e...

Re: Extremely Linear Git History

#98

Post by unnah »

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…

Next step: a svn-git proxy that allows one to use a subversion client with a remote git repository.

Re: Extremely Linear Git History

#99

Post by silon42 »

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…

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.

Re: Extremely Linear Git History

#100

Post by piskerpan »

silon42 wrote: post #99
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…

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.

If you’re merging (and not rebasing) it’s the same exact thing. You’re just switching the “incoming” version, but conflicts will be identical.
Post reply on HN