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

31–40 of 116 posts

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

#31

Post by wakawaka28 »

hansonkd wrote: post #12
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 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.

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.

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

#32

Post by wakawaka28 »

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.

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 people to coordinate their work too.

The main reason people want to rebase instead of merging is to keep the commit history from looking like a bowl of spaghetti. A commit history like that is hard to navigate, and more likely to contain a lot of frivolous edits.

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

#33

Post by wakawaka28 »

Etheryte wrote: post #25
mplanchard wrote: post #11

Configuring rerere makes a huge difference in overall rebase experience. The following is a standard addition to my gitconfig [rerere] enabled = true autoupdate = true

Somehow, despite using Git for who knows how many years, I haven't seen rerere yet. I read the manpage for it, but the usage isn't exactly clear about any possible pitfalls. Are there any gotchas? Where and how do you usually use it?

You don't have to do anything besides turning it on. If a conflict has been resolved before, somehow it remembers that and applies the fix. The only pitfall I've seen is if you fix the conflict erroneously, it will remember that too.

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

#34

Post by hansonkd »

wakawaka28 wrote: post #31
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.

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.

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

#35

Post by dimal »

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

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

#36

Post by nh2 »

hansonkd wrote: post #12
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 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.

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

#37

Post by PaulDavisThe1st »

wakawaka28 wrote: post #33
Etheryte wrote: post #25

Earlier quoted context omitted.

Somehow, despite using Git for who knows how many years, I haven't seen rerere yet. I read the manpage for it, but the usage isn't exactly clear about any possible pitfalls. Are there any gotchas? Where and how do you usually use it?

You don't have to do anything besides turning it on. If a conflict has been resolved before, somehow it remembers that and applies the fix. The only pitfall I've seen is if you fix the conflict erroneously, it will remember that too.

Yes, my general rule of thumb as a rerere user and devotee is to at the very least do a test build before git-add'ing your resolved files. You won't catch logical errors, but you will catch syntactical issues that came up during conflict resolution. It helps, a bit.

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

#38

Post by samatman »

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.

I don't understand why this would make a difference.

Any given snapshot has a linear history, so it should be as bisectable as the rebased equivalent. What am I missing here?

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

#39

Post by jjmarr »

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.

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

#40

Post by Arelius »

samatman wrote: post #38
nh2 wrote: post #36

Earlier quoted context omitted.

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.

I don't understand why this would make a difference. Any given snapshot has a linear history, so it should be as bisectable as the rebased equivalent. What am I missing here?

Agreed… I think people like to think bisect doesn’t work with merges also.
Post reply on HN