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

221–230 of 366 posts

Re: Extremely Linear Git History

#221

Post by couchand »

benatkin wrote: post #211
GuB-42 wrote: post #86

Earlier quoted context omitted.

> I want the 'merge' function completely deprecated. I simply don't trust it anymore. Merge is perfectly fine and it is the only way to synchronize repositories without changing the history, which is very important for a decentralized system. It certainly has the potential to make a mess if used improperly, but so do rebase, cherry-pick, and basically every other command. > If you use merge to sync two branches conti…

Proper use of merge is table stakes. You get warned in your PR if your non-main branch is out of date with your main branch, and after you rebase and force push your non-main branch, you review the diff in the PR.

Then you don't actually need merge? Am I missing something?

If you always rebase the branch, the commits can be applied directly.

Re: Extremely Linear Git History

#222

Post by thargor90 »

gpvos wrote: post #154
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 there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. I don't get it. If you rebase, you get 20 chances to do the same.

Reviewing merge commits is harder because they will sometime have huge diffs to both branches.

Rebasing is the process of redeveloping your feature based on the current master. This is smaller, easier steps to review later.

It is a pitty that we can't have tooling to create "hidden" merge commits to allow to connect rebased branches, this would retain the history better and allow pulling more easily.

Re: Extremely Linear Git History

#223

Post by diekhans »

blux wrote: post #153

I fail to see the point of this, in fact, I think this is a fundamentally flawed approach to dealing with your revision history. The problem is that rebasing commits has the potential of screwing up the integrity of your commit history. How are you going to deal with non-trivial feature branches that need to be integrated into master? Squash them and commit? Good luck when you need to git bisect an issue. Or rebase a…

It is amazing how much time projects seem to spend on rewriting history for the goal of displaying in in a pretty way. Leaving history intact and having better ways to display it seems far saner. Even after a merge, history in the branch maybe useful for bisect, etc.

Re: Extremely Linear Git History

#224

Post by couchand »

Beltalowda wrote: post #200
broeng wrote: post #91

Earlier quoted context omitted.

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.

> It seems like a very contrived example to me. I run in to this quite frequently, even on projects where I'm the only one working on it (I tend to have a lot of things going on in parallel). Once branches diverge and commits accumulate it can become a right pain. Usually my solution is to merge master into the branch just to keep up to date and then just undo everything, make one new commit in the master, and rebase…

> arguably I shouldn't have all these long-lived branches in the first place

This is the problem here. If you have multiple long-lived branches, there's no technical solution to preventing rot -- you must actively keep them in sync.

Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution.

Re: Extremely Linear Git History

#225

Post by ChrisMarshallNY »

actuallyalys wrote: post #220
ChrisMarshallNY wrote: post #25

I find tags to be a fairly useful way of providing a linear progression, but I guess that's no fun. > but it can also mean to only allow merges in one direction, from feature branches into main, never the other way around. It kind of depends on the project. That sounds like the Mainline Model, championed by Perforce[0]. It's actually fairly sensible. [0] https://www.perforce.com/video-tutorials/vcs/mainline-model-...

Yeah, I think tags are a more practical way of accomplishing this. If you’re really interested in having a linear history, it might also make sense to switch to an alternative. Mercurial has linear version numbers and can even push to Git repositories. At risk of coming across as a humorless Hacker News commenter, I will add that I enjoyed this post. It’s a neat hack!

Yes, it is a cool hack. I enjoy these, even if I can't find a practical application.

Re: Extremely Linear Git History

#226

Post by yamtaddle »

gyulai wrote: post #67
MAGZine wrote: post #45

Earlier quoted context omitted.

... What are the other reasons?

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…

It's worth having distributed version control just so you can work on your own with your own branches and crap and only bother others when you're ready to share. And so you can work seamlessly when offline.

SVN feels like working in someone else's kitchen while several other people are trying to cook in it, too. It's hell. I prefer that we each have our own kitchen and bring our dishes to the table when they're ready.

I've also repeatedly found git a suitable (if not great—if they'd put all their effort behind libgit2 and make that the official implementation, that'd help a ton) tool to form the foundation of larger systems. It's a damn fine toolbox for attacking certain problems. SVN wouldn't have been much help in any of those situations.

Re: Extremely Linear Git History

#227

Post by wnoise »

u801e wrote: post #115
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…

What I would like to see is a way to enforce fast-forward only merges along with the forced creation of a merge commit that references the same git tree as the HEAD commit of the branch that was just merged. This way, you know which set of commits was in the branch by looking at the parent commits of the merge commit, but the merge commit itself did not involve any automated conflict resolution.

Yes, it is a shame that you can't combine git merge --ff-only --no-ff .

Re: Extremely Linear Git History

#228

Post by pqdbr »

couchand wrote: post #224
Beltalowda wrote: post #200

Earlier quoted context omitted.

> It seems like a very contrived example to me. I run in to this quite frequently, even on projects where I'm the only one working on it (I tend to have a lot of things going on in parallel). Once branches diverge and commits accumulate it can become a right pain. Usually my solution is to merge master into the branch just to keep up to date and then just undo everything, make one new commit in the master, and rebase…

> arguably I shouldn't have all these long-lived branches in the first place This is the problem here. If you have multiple long-lived branches, there's no technical solution to preventing rot -- you must actively keep them in sync. Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution.

How do you constantly rebase on top of main if more than one person is working on the feature branch?

Re: Extremely Linear Git History

#229

Post by couchand »

pqdbr wrote: post #228
couchand wrote: post #224

Earlier quoted context omitted.

> arguably I shouldn't have all these long-lived branches in the first place This is the problem here. If you have multiple long-lived branches, there's no technical solution to preventing rot -- you must actively keep them in sync. Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution.

How do you constantly rebase on top of main if more than one person is working on the feature branch?

recursion

Re: Extremely Linear Git History

#230

Post by e40 »

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 have never had issues with merge, unless rerere was enabled. I've had some extremely surprising results recently with it enabled and I finally disabled it for good.
Post reply on HN