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

41–50 of 116 posts

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

#41

Post by Arelius »

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.

I think no. It’s the same compulsion that leads to bike shedding in code review.

And honestly, there are far too many engineers that use rebase without understanding the underlying system which is dangerous in git. (Aside, I wish git would adopt hg’s stages)

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

#42

Post by Arelius »

jjmarr wrote: post #39
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.

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?

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

#43

Post by nguyenkien »

dimal wrote: post #35

Off topic but why do product blogs always exist on a separate domain, with no link to the product website? I never heard of GitButler. Reading this is making me curious about it. But the home link in the top left goes to the blog home. If I want to actually see the product, I have to manually edit the url, on my iPad. Why does everyone do this? Seems obvious to have a link to the main site. /rant

Home website link in menu button.

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

#44

Post by Arelius »

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 tend to agree. While I am normally super pro-merging. I agree that for maintaining a fork, the patch set style rebase workflow is preferable.

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

#45

Post by hughesjj »

keybored wrote: post #20
frizlab wrote: post #15

Earlier quoted context omitted.

Force push should be “with lease” by default. Then force pushing is not dangerous at all.

It’s still dangerous if you have fetched recently. You also might want `--force-if-includes`. (And then I don’t think there are any more “force” flags left to worry about…!) https://stackoverflow.com/questions/65837109/when-should-i-u...

I really wish there was a global setting to turn this on by default/in config but afaik for backwards compatibility reasons Linus doesn't want to do that so the advice I've heard is to just configure it as an alias

Personally, I'm lazy and just always have it in recent substring match history in the shell

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

#46

Post by throwaway918299 »

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.

merge feature branches when reintegrating main, squash merge onto the main branch when you’re finished - best of both worlds imo

I never need to rebase, or unfuck a botched rebase or go reflog diving - and the commit history is linear where it matters.

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

#47

Post by fallingsquirrel »

jjmarr wrote: post #39
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.

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 finding out when you rewrote history.

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

#48

Post by ilyagr »

mdaniel wrote: post #26

cute: https://github.com/gitbutlerapp/gitbutler/blob/v0.10.0/LICEN...

They have a few blog posts about this license: https://blog.gitbutler.com/gitbutler-is-now-fair-source/, https://blog.gitbutler.com/the-future-of-open-source/

I don't think they are the first ones to open-source their code on a timer, but they are trying to popularize the idea.

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

#50

Post by kazinator »

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.

This branch discussion doesn't speak to the present topic (much). Merging involves rebasing, possibly requiring conflict resolution.

Merge versus rebase is just git speak for two different ways of tracking things when diverging streams recombine.

In a nutshell, merge creates a single new commit which brings all the cumulative changes from a source branch onto the target. The commit has two parents: the prior commit on the destination branch and the commits on the source branch.

Rebase creates a new commit out of every individual commit on the branch, bringing them individually into the target branch, much as if they were being merged. However, they have only one parent: their target branch lineage.

(Rebasing is way better from a conflict point of view because the changes are individually brought in. A merge creates a "patch bomb" on the destination branch in which serveral totally unrelated conflicts might have been resolved, pertaining to different commits in the original.)

Post reply on HN