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

81–90 of 116 posts

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

#81

Post by globular-toast »

lmm wrote: post #63
globular-toast wrote: post #14

Earlier quoted context omitted.

I think you're doing it wrong. The point of rebasing is to do it often, like every day at the very least for an active integration branch. This hopefully means you'll resolve any conflicts as soon as they happen, while it's still fresh in everyone's heads. If you rebase once right at the end then, sure, it's no different to merging.

> The point of rebasing is to do it often, like every day at the very least for an active integration branch. This hopefully means you'll resolve any conflicts as soon as they happen, while it's still fresh in everyone's heads. You can do that with merge just as easily though - just merge master into your branch.

Yes but at that point you might as well squash down to one commit and rebase because now you're tracking "history" which is useless, rather than tracking changes/versions.

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

#82

Post by eviks »

_ugfj wrote: post #23

I must admit I usually immediately disregard any fancy new git tools, they come and go and often don't work right and create a gigantic mess. But... have you seen who wrote this article? Scott Chacon. If there's anyone in this world whose article would make me try a new git tool, it's him. He wrote the Pro Git book, Git Internals. Oh and cofounded GitHub. This is not argument from authority fallacy. This is "hey! thi…

This is precisely the argument from authority fallacy, though a bit more grounded than the strong prejudice with a gigantic mess

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

#84

Post by Ferret7446 »

PhilipRoman wrote: post #13
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's a big deal when maintaining a fork. It's tempting to merge upstream commits back into your branch, but you should always rebase and keep a clean patch set in such situation.

I don't understand how you are using rebase with a fork. Are you rebasing all of the changes in your fork on top of upstream? That list of changes will grow larger over time; after a year, you'd be rebasing hundreds of commits whenever you want to merge upstream.

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

#85

Post by globular-toast »

everybodyknows wrote: post #69
globular-toast wrote: post #18

Earlier quoted context omitted.

As long as you commit everything, yes. The reflog is the safety rope of git. Everyone who isn't confident with the reflog should go and learn it right now. Pick your most important repo. Make sure everything is committed. Doing something stupid like `git reset --hard HEAD~100`. Look how fucked your work is. Do `git reset --hard HEAD@{1}`. Look at how nothing was lost.

> reflog should go and learn it Among its other virtues, reflog makes safe the highly empowering 'git-commit --amend'.

Yep, and even the more powerful fixup workflow where you can essentially amend commits other than HEAD. I do it via git-autofixup: https://github.com/torbiak/git-autofixup

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

#86

Post by PhilipRoman »

Ferret7446 wrote: post #84
PhilipRoman wrote: post #13

Earlier quoted context omitted.

It's a big deal when maintaining a fork. It's tempting to merge upstream commits back into your branch, but you should always rebase and keep a clean patch set in such situation.

I don't understand how you are using rebase with a fork. Are you rebasing all of the changes in your fork on top of upstream? That list of changes will grow larger over time; after a year, you'd be rebasing hundreds of commits whenever you want to merge upstream.

A friendly fork generally has a natural limit on how many commits there will be on top. Personally I've done this with ~200 feature commits and it's not a big problem (as long as you use incremental rebase of course).

Of course if you're planning a hard fork, merges may be unavoidable. But I've seen too many Franken-linux-kernels which were forked from 4.x with periodic merges whose correctness is impossible to verify. Inconsistencies eventually build up with each merge.

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

#87

Post by globular-toast »

epolanski wrote: post #29
globular-toast wrote: post #14

Earlier quoted context omitted.

I think you're doing it wrong. The point of rebasing is to do it often, like every day at the very least for an active integration branch. This hopefully means you'll resolve any conflicts as soon as they happen, while it's still fresh in everyone's heads. If you rebase once right at the end then, sure, it's no different to merging.

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.

So here's the thing: if you are putting more work into rebasing but not getting anything more out of it, you are doing it wrong.

You should always do the easiest thing that gets you what you want, otherwise you're just doing pointless work. If you and your colleagues are happy merging and you find that easier, that's what you should be doing.

Rebasing supports a totally different workflow. With a rebase I can submit a well-formed set of changes for review that are conflict free. You can't do that with merging. With merging you submit a bunch of crap "history" that nobody will ever look at and the project maintainer has to deal with the conflicts.

Merge commits look like this (newest to oldest):

    * Final tweaks
    * Merge master branch
    * Implement bar
    * Fix foo
    * Merge master branch
    * Shit I did on Wednesday before lunch
    * Implement foo
    * End of day
Totally impenetrable mess that nobody will ever look at.

Rebased commits look like this:

    * Add customise option to UI
    * Add use case baz
    * Extend model to support bar
    * Refactor model foo
These can be reviewed in insolation and when approved they merge without conflict.

If you want to do this but none of your colleagues are on board and you don't have the swing to make them, then I'm sorry. But you are wasting your time rebasing in that case. :(

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

#88

Post by not_kurt_godel »

epolanski wrote: post #28
hinkley wrote: post #21

Earlier quoted context omitted.

I spend a lot of time cleaning up after people who insist there are no b problems in their code despite all evidence to the contrary. That work is easier when they haven’t squashed their changes. Because I can see how they got there and if it was a mistake or a misunderstanding. People who prefer squash are an automatic red flag because they usually don’t like asking Why, which is a very important skill on products t…

Issues should be catched by spending time in automating tests that ensure the correct functional and non functional requirements are met not by surgically maintaining a graph of codebase snapshots. History is preserved in the branch along the PRs if needed, and it rarely is. I'm not saying that rebasing is useless (I default to it), I'm debating if the effort is worth it in engineering terms, which I generally don't…

The graph of snapshots is for forensics when someone breaks the tests and keeps obliviously trucking along

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

#89

Post by obeavs »

_ugfj wrote: post #23

I must admit I usually immediately disregard any fancy new git tools, they come and go and often don't work right and create a gigantic mess. But... have you seen who wrote this article? Scott Chacon. If there's anyone in this world whose article would make me try a new git tool, it's him. He wrote the Pro Git book, Git Internals. Oh and cofounded GitHub. This is not argument from authority fallacy. This is "hey! thi…

Gitbutler is ridiculously cool and well considered. Definitely worth checking out.

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

#90

Post by seanwilson »

epolanski wrote: post #28
hinkley wrote: post #21

Earlier quoted context omitted.

I spend a lot of time cleaning up after people who insist there are no b problems in their code despite all evidence to the contrary. That work is easier when they haven’t squashed their changes. Because I can see how they got there and if it was a mistake or a misunderstanding. People who prefer squash are an automatic red flag because they usually don’t like asking Why, which is a very important skill on products t…

Issues should be catched by spending time in automating tests that ensure the correct functional and non functional requirements are met not by surgically maintaining a graph of codebase snapshots. History is preserved in the branch along the PRs if needed, and it rarely is. I'm not saying that rebasing is useless (I default to it), I'm debating if the effort is worth it in engineering terms, which I generally don't…

> I'm not saying that rebasing is useless (I default to it), I'm debating if the effort is worth it in engineering terms, which I generally don't see because the benefits seem to be small compared to the cost.

For what's it worth, I agree for most projects I've been on. I've rarely e.g. used deep Git history forensics to figure out a regression, or to figure out why some code is the way it is. Usually I'm just tracking down the fairly recent squashed commit of a pull request that introduced the problem and it's obvious enough where to look to fix it.

I like the idea of clean, super fine-grained commits with good summaries but I never see people mention that this takes extra time to do, because putting a pull request together is usually a messy iterative process, and not a predictable sequence of clean independent commits.

Real work is more like "Add sketch of code ... Iterate some more ... Fix bug ... Iterate some more ... Upgrade library ... Really fix the bug ... Clean up ... Merge from main and get working ... Refactor ... Add comments ... Fix PR requests". Rebasing as you go or going back at the end to break that into chunks that will each independently make sense and pass tests costs a lot of time? Maybe I'm missing something?

The time vs benefit trade-off is probably different with huge teams and huge projects, but for solo projects, small teams, and medium projects the trade-offs are different.

Feels similar to test suite discussions. People don't mention there's a cost vs benefit trade-off to how fine grained your tests should be for different scenarios as it depends on a lot of factors you need to balance.

Post reply on HN