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

GitButler now supports first class conflicts, making rebasing less annoying

blog.gitbutler.com

Post reply on HN
Print view View original

51–60 of 116 posts

Re: GitButler now supports first class conflicts, making rebasing less annoying

#51

Post by rontdrr2 »

hansonkd wrote: post #34
wakawaka28 wrote: post #31

Earlier quoted context omitted.

A linear commit history is objectively better. But whether it's worth the effort to maintain is up to you to decide. If your branches don't stay unmerged for long, then you're probably better off rebasing instead of generating tons of little branches for no reason.

Objectively better to what? Git usage is only one part of a wider engineering org. That like saying "bugless code is objectively better" without considering time to delivery, engineering resources, etc.

[dead]

Re: GitButler now supports first class conflicts, making rebasing less annoying

#52

Post by lmz »

fallingsquirrel wrote: post #47
jjmarr wrote: post #39

Earlier quoted context omitted.

I was on a team where we wrote software tests for computer hardware. Regressions were frequent. The underlying hardware wasn't very reliable because it was all very early-stage and hadn't been tested yet (as it was our job to write the tests in the first place). The linear commit history created by rebasing made it trivial to bisect and determine what introduced the problem. Huge difference to my productivity.

git bisect will traverse both parents of a merge commit no problem. Did you try? In your situation I'd prefer merges because: if commit X used to have parent A, and you move it over to parent B, it gets a new commit hash and a version of the code that has never been tested. If that commit is broken: was it broken when the author wrote it, or did it only break when you rebased? You threw away your only means of findin…

From their perspective what's the difference? It would be better if after rebasing all resulting commits were tested automatically, but even if they were not - the offending commit is still wrong "in context".

Re: GitButler now supports first class conflicts, making rebasing less annoying

#53

Post by kazinator »

fallingsquirrel wrote: post #47
jjmarr wrote: post #39

Earlier quoted context omitted.

I was on a team where we wrote software tests for computer hardware. Regressions were frequent. The underlying hardware wasn't very reliable because it was all very early-stage and hadn't been tested yet (as it was our job to write the tests in the first place). The linear commit history created by rebasing made it trivial to bisect and determine what introduced the problem. Huge difference to my productivity.

git bisect will traverse both parents of a merge commit no problem. Did you try? In your situation I'd prefer merges because: if commit X used to have parent A, and you move it over to parent B, it gets a new commit hash and a version of the code that has never been tested. If that commit is broken: was it broken when the author wrote it, or did it only break when you rebased? You threw away your only means of findin…

What you need is a "git rebase" that records a second parent for each commit pointing to the original commit that is being rebased.

People who prefer git rebase workflow will hate the complicated history they see in "git log", but otherwise it will be the same.

Alternatively, the right way to use "git merge" is to merge every successive commit of a branch one by one.

The problem with "git merge" is that it collapses multiple commits into one giant patch bomb.

If one of the commits caused a problem, you don't have that commit isolated on the relevant stream (the trunk) where you are actually debugging the problem.

You know that the merge introduced a problem, and it seems that it was a particular commit there. But you don't have that commit by itself in the stream where you are working.

It can easily be that a commit which worked fine on a branch only becomes a problem in its merged form on the trunk, due to some way a conflict was resolved or whatever other coincidence or situation. Then, all you know is that the giant merge bomb caused a problem, but when you switch to the branch, the problem does not reproduce and thus cannot be traced to a commit.

If that commit is individually brought into the trunk, the breakage associated with it will be correctly attributed to it.

In both cases, the source material the same: the original version of the commit doesn't exhibit the problem on its original branch.

It is pretty important to merge the individual changes one by one, so that you are changing fewer things in one commit.

People like rebase because it does that one by one thing. Git rebase breaks the relationship by not recording the extra parents, but since they have the reworked version of each change on the stream they care about, they don't care about that. Plus they like the tidy linear history.

Re: GitButler now supports first class conflicts, making rebasing less annoying

#54

Post by hinkley »

sunshowers wrote: post #27
hinkley wrote: post #22

Earlier quoted context omitted.

I have to use reflog, rebase -i and frequent commits to cover the spectrum of edge cases I deal with weekly. No two of them accomplish the entire job.

You should try out Jujutsu :)

It's on my list.

Re: GitButler now supports first class conflicts, making rebasing less annoying

#55

Post by hughesjj »

wakawaka28 wrote: post #32
epolanski wrote: post #29

Earlier quoted context omitted.

I'm not doing it wrong, I'm questioning whether it's worth the effort. I have spent hours rebasing on very active branches when a merge would've taken minutes (as many colleagues do) just because "it's a best practice" but I've never got to fully appreciate the benefits.

You don't have to keep rebasing your entire history on long-running branches. That will generate a ton of conflicts. But before you wrap it up it would be preferable for you to reduce your changes into one or a handful of stand-alone commits. If you're going to rebase often onto very active branches then you need to reduce the commits as much as possible to minimize the work involved. Ideally you could get other peop…

Also if you use rerere you don't really spend much time doing repetitive rebases after the first rebase

Re: GitButler now supports first class conflicts, making rebasing less annoying

#56

Post by lmm »

imiric wrote: post #10

I have yet to try Jujutsu or GitButler, but Git has a built-in way to make conflict resolution a bit easier with `rerere`. To be honest, I don't find doing this work manually a major chore, so I don't enable it, but it's there if you need it. I would like to comment on this: > I have been asked countless times if it's better to merge or to rebase and while I never want to stir up a hornet's nest, I have always advoca…

The fears are legitimate. Both rebase and force-push can lose data in some circumstances, which merge and push cannot. Yes, there are strategies which, if followed perfectly, allow one to avoid losing data when doing rebase and/or force-push. But those strategies are not simple to describe, especially to newcomers, and in practice people make mistakes; all else being equal, an inherently safe workflow is better.

Re: GitButler now supports first class conflicts, making rebasing less annoying

#57

Post by lmm »

lmz wrote: post #52
fallingsquirrel wrote: post #47

Earlier quoted context omitted.

git bisect will traverse both parents of a merge commit no problem. Did you try? In your situation I'd prefer merges because: if commit X used to have parent A, and you move it over to parent B, it gets a new commit hash and a version of the code that has never been tested. If that commit is broken: was it broken when the author wrote it, or did it only break when you rebased? You threw away your only means of findin…

From their perspective what's the difference? It would be better if after rebasing all resulting commits were tested automatically, but even if they were not - the offending commit is still wrong "in context".

Rebase can result in a long chain of commits that don't compile, which makes it impossible (or at least harder) to use automated bisect, or even semi-manual approaches like running a test case manually on each bisect step.

Re: GitButler now supports first class conflicts, making rebasing less annoying

#58

Post by kazinator »

Arelius wrote: post #42
jjmarr wrote: post #39

Earlier quoted context omitted.

I was on a team where we wrote software tests for computer hardware. Regressions were frequent. The underlying hardware wasn't very reliable because it was all very early-stage and hadn't been tested yet (as it was our job to write the tests in the first place). The linear commit history created by rebasing made it trivial to bisect and determine what introduced the problem. Huge difference to my productivity.

Did you ever try bisection without the linear history to compare? Or was this just conjecture?

I have. It was a complete fucking shitshow. In a kernel tree, doing a git bisect with the messy merge history will take you on a wild goose chase, where you land in some branch developed by an entirely different team somewhere, working on totally different hardware from you, with a different kernel version, which you have no hope of building and booting.

Re: GitButler now supports first class conflicts, making rebasing less annoying

#59

Post by lmm »

nh2 wrote: post #36
hansonkd wrote: post #12

Earlier quoted context omitted.

It always seemed like a needless complexity when you can just merge and get the same result in terms of the state of the files, just with a different commit history. The only time it might make sense if you are following some arbitrary strict style guidelines for commits. Some people care more about the commit history than others, not that either way is necessarily better.

git bisect. I have a friend, he thought rebasing for linear history was not worth the effort. I told him to do it, because I once had to find a regression over thousands of commits in a merge-heavy code base and it took days. He was not convinced. Then he had to find a regression. It took over a month. With git bisect's binary search, it would have taken half a day. My friend now rebases.

bisect works much better with merge than it does with rebase (with rebase it's easy to end up with a long chain of commits that don't compile, so your automated bisect script doesn't work).

Re: GitButler now supports first class conflicts, making rebasing less annoying

#60

Post by kazinator »

keybored wrote: post #17
epolanski wrote: post #9

Serious question: how many times the pain of going through rebases rather than merges made a difference, or even better, really paid off in engineering terms? To me it's virtually zero in seven years but it might be due to the teams and projects I've been involved with.

It isn’t always harder than doing a merge. > really paid off in engineering terms? When you want your changes accepted by upstream and they either 1. Won’t accept a merge-filled history 2. Indirectly won’t because they accept changes by email (can’t send merges by email)

The main reason they should not accept merges is that they don't care about you and your repo. In order for an upstream repo to accept your work as a git merge, they would have to fetch all your objects so that they have enough of your repo in order to represent your original branch, where the parent pointers of the merge are aimed. Nobody who is anywhere near sane wants that kind of cruft.
Post reply on HN