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

61–70 of 116 posts

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

#61

Post by lmm »

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.

> A linear commit history is objectively better.

Disagree. You can always flatten a commit graph into a linear history if you want, but you can't restore the original commit graph from a linear history. So preserving the original history is objectively better.

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

#62

Post by rontdrr2 »

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…

[dead]

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

#63

Post by lmm »

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.

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

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

#64

Post by lmm »

throwaway918299 wrote: post #46
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.

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.

Makes the history less useful for bisection - you'll always land on a squash merge rather than the specific commit that caused the problem.

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

#65

Post by kazinator »

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.

The linear part of the history is objectively better than if that same change were collapsed into a single patch bomb.

Git rebase does not destroy history, it just does not link it together. That might be a bad thing. But the individual commits all making an appearance on the destination branch is a good thing.

From those who favor merge, what is bad is that there are no second parent pointers tracking where those changes came from.

This coulid be obtained by reimplementing git rebase as a sequence of merges. Git rebase is a sequence of zero or more cherry picks, not merges. If git rebase merged each commit instead of cherry picking, each commit would have a parent pointing to its original.

In a git bisect, there would be no need to chase those second parents; you would be looking for which merged commit introduced the breakage, and not care about its original, except in some rare situations where you want to analyze more deeply what went wrong (and then that parent pointer would be a bit handy).

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

#66

Post by lmm »

_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…

More importantly IMO he wrote the github-flow post, the best dose of sanity in git workflows I've seen.

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

#67

Post by hughesjj »

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…

This argument seems weird to me because even without rerere I found myself doing a lot more work managing merge conflicts with git merge instead of git rebase

As a git merge fan, are there any tips or tricks you suggest beyond the stock git experience when doing git merge to minimize the amount of merge conflicts you get?

I found it was especially bad when doing a git merge on a refactor, but I admit it could just be that I abandoned git merge earlier in my career before switching to rebase and never properly learned it

My most common use cases are feature or bug branches with a lifespan between less than one day and up to one month (although I absolutely have some features on pause for even over a year, in which case interactive git rebase and partially squashing WIP commits is my current method of updating)

All this is for repos from literally just me, to a few changes a month between 3 devs, to 5-2 devs doing multiple commits per day, to some open source projects with commits landing every few minutes from multiple devs if it's like a release day

My current biggest issue with rebase is verified commits with GitHub and a bit of guilt for rewriting committed feedback from other authors on my PRs

The only time I really use git merge is when I want to see how my work interplays with more than one feature branch at once, or if the feature branch I want to integrate hasn't rebases themselves in a bit and conflicts occur

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

#68

Post by hinkley »

wakawaka28 wrote: post #30
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…

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

> That sounds like a problem with the people you work with

No, it says something about me, not them. When people can't figure out problems on their own they come to me for help. Have been since I was a sophomore in college, which was a long ass time ago. Possibly before you were born (8 month account). So I have a pretty good idea where 'rock bottom' is for every class of tool I've ever used, and how often people get close to them.

I also get called in to look at bugs that other people refuse to believe exist, and bug forensics is where you really, really see the difference between a good commit history and a shitty one. If you aren't using 'git annotate' weekly or daily then you are not qualified to comment on how merges should or shouldn't be done. "I don't use it" means you don't have an opinion. "... so you shouldn't use it" is telling your coworkers you don't give a shit.

> This is a wild generalization

I think you're confusing red flag with deal breaker.

> Thoughtful people squash when they think they have a set of changes that go together.

True but useless distinction. Define 'go together'. Everyone has a different definition of this and you will never reach consensus there. Most of the people I'm thinking of here think everything for a single story 'goes together'. This is how you get an initial commit for a new module with 600+ lines of code and eight bugs you have to solve the hard way because all of the bugs showed up in a single commit.

Squashing before a PR fails Knuth's aphorism about code being meant to be read by humans and only incidentally by machines.

If you don't like that it took you three tries to figure out an off by one error in your code, that's fine. But you don't have to destroy all other evidence of your other processes in order to cover up your brainfart.

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

#69

Post by everybodyknows »

globular-toast wrote: post #18
johnea wrote: post #3

With syslog, everything in git is "fearless"

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

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

#70

Post by hinkley »

hughesjj wrote: post #67
epolanski wrote: post #28

Earlier quoted context omitted.

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…

This argument seems weird to me because even without rerere I found myself doing a lot more work managing merge conflicts with git merge instead of git rebase As a git merge fan, are there any tips or tricks you suggest beyond the stock git experience when doing git merge to minimize the amount of merge conflicts you get? I found it was especially bad when doing a git merge on a refactor, but I admit it could just be…

Most of the time I've encountered two engineers pointing fingers about who is responsible for a bug, it turns out that someone's bad merge transferred the git annotation from one engineer to another.

The first time this happened (that I caught) I had two engineers who were sniping at each other. One was older "Max" and not great at data structure algorithms. The other "Stan" was a decent coder but had a bad attitude and was awful with git. Somehow he thought he could raise his status by getting Max kicked off the team.

I come back from lunch one day and Stan is bitching about a bug in Max's new code that's causing issues. To keep these two from fighting I've been reviewing all of Max's PRs and the line of code Stan is complaining about I know for a fact I checked, and was relieved to see Max got it right the first time. But sure enough, the repo says Max fucked it up.

Twenty minutes of git archaeology later and sure enough, Stan messed up a merge and resolved the conflict wrong, introducing the phantom bug. So I showed him the step by step of my diagnosis and then we had another little talk about using rebase.

Post reply on HN