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

21–30 of 116 posts

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

#21

Post by hinkley »

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 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 that are shipping and making money.

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

#22

Post by hinkley »

sunshowers wrote: post #5
johnea wrote: post #3

With syslog, everything in git is "fearless"

Assuming this is the reflog, this is not true. Because the working copy doesn't get snapshotted, it is relatively easy to lose uncommitted data. I've spent much of my professional career working on source control and even I've lost uncommitted data a few times. Dropbox doesn't have a notion of uncommitted data. Why should source control?

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.

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

#23

Post by _ugfj »

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! this guy knows git like very very few others, it's worth listening to what he has to say".

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

#25

Post by Etheryte »

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?

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

#27

Post by sunshowers »

hinkley wrote: post #22
sunshowers wrote: post #5

Earlier quoted context omitted.

Assuming this is the reflog, this is not true. Because the working copy doesn't get snapshotted, it is relatively easy to lose uncommitted data. I've spent much of my professional career working on source control and even I've lost uncommitted data a few times. Dropbox doesn't have a notion of uncommitted data. Why should source control?

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 :)

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

#28

Post by epolanski »

hinkley wrote: post #21
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 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 see because the benefits seem to be small compared to the cost.

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

#29

Post by epolanski »

globular-toast wrote: post #14
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 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.

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

#30

Post by wakawaka28 »

hinkley wrote: post #21
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 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…

>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.

That sounds like a problem with the people you work with, not with squashing in general.

>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 that are shipping and making money.

This is a wild generalization. Thoughtful people squash when they think they have a set of changes that go together. If someone is jamming together stuff that does not go together then that is indeed a problem, but not a problem with squash. Nobody really wants to see the 50 edits someone made to come up with one final change.

Post reply on HN