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

91–100 of 116 posts

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

#91

Post by wakawaka28 »

lmm wrote: post #61
wakawaka28 wrote: post #31

Earlier quoted context omitted.

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.

The original history is usually a bunch of garbage. If you need more detail you can rebase as many commits as you like. More detailed history is sometimes a distinct problem. Imagine trying to bisect some spaghetti bowl of commits with merges to find the source of a recurring issue. It would be relatively nonsensical compared to a clean linear history.

Clean history can exist with merges, but I think merging all over the place obviously encourages messy behaviors.

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

#92

Post by wakawaka28 »

hansonkd wrote: post #34
wakawaka28 wrote: post #31

Earlier quoted context omitted.

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.

Better to work with of course. If you have valid reasons to have branches, such as a need to ship multiple versions, I don't have a problem with that. But day-to-day work is better done via rebasing rather than making a ton of public branches that get merged. If you know what you're doing then rebasing is just as easy as merging. As others have said, git rerere helps a lot too.

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

#93

Post by Quekid5 »

hinkley wrote: post #68
wakawaka28 wrote: post #30

Earlier quoted context omitted.

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

I tend to think a major contributory factor to the indifference (at best) about commit hygiene is that people vastly underestimate the power of "show commit history for this range of lines" in modern IDEs/GUIs for Git.

It's incredibly powerful for (just from decent commit messages) figuring out why some little detail in the code is the way it is.

I'm thankful every day that I get to mandate Gerrit (so rebased-patches-on-top-of-main) workflow with every individual commit going through CI.

ETA: Incidentally, I'm usually also someone who often gets called in to figure out obscure-yet-important bugs... and the commit log is instrumental to that.

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

#94

Post by wakawaka28 »

hinkley wrote: post #68
wakawaka28 wrote: post #30

Earlier quoted context omitted.

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

>No, it says something about me, not them.

OK I totally see that now.

Speaking of red flags, your whole comment is a red flag to me, just like mentioning that common workflows are "red flags" lol.

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

More narcissistic garbage takes. There are many ways to work and if someone doesn't do it your favorite way then that doesn't mean they are reckless, incompetent, or whatever. If you told this to anyone I work with or have ever worked with in real life in the last 20 years, you'd get laughed at. I might know a lunatic who would argue with you in real life but even he might not be motivated enough to take the bait. He is a very junior-minded person as well, whose experience does not match his interests.

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

This is too reductive. You have to use common sense when squashing stuff. If you put stuff together that does not go together, then it gets harder to figure out what a changeset is supposed to do.

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

There need be no evidence of "processes" in the end. I can see why you might want that if you're helping your coworkers figure something out. But once it's figured out then those changes should be reduced to modular changesets that each do a particular thing. Anything else will introduce pointless noise into the codebase. If you feel that some particular state of the code represents something significant, you can make a commit for that. But certainly 80% of the commits most people make are purely noise.

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

#95

Post by seanwilson »

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

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…

Doesn't the rebased commits example take longer to put together than the merge commits example (where you'd likely want to just squash the merge commits)?

The merge version looks like the way code is actually written in practice to me, so doesn't the rebased version take extra time to create after you're done adding code? E.g. the "Add use case baz" rebase commit isn't likely to be a simple squashing of commits from the merge version, but cherrypicking specific lines from multiple commits.

I fully agree the rebased version is nicer, but I'm not seeing anyone talk about how much extra time it takes. Or you're doing it in a way that doesn't take much time somehow?

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

#96

Post by sangnoir »

imiric wrote: post #10

I have yet to try Jujutsu or GitButler, but Git has a built-in way to make conflict resolution a bit easier with `rerere`. To be honest, I don't find doing this work manually a major chore, so I don't enable it, but it's there if you need it. I would like to comment on this: > I have been asked countless times if it's better to merge or to rebase and while I never want to stir up a hornet's nest, I have always advoca…

> I've been involved in this discussion many times as well, and the correct answer is that one isn't inherently "better", and you shouldn't _always_ prefer one over the other.

That depends entirely on your organization's (or project's) preferred branching strategy and what is accepted as a unit of change: Some accept entire features as a single commit (via squash merging dev/feature branches - very useful when you have to maintain multiple release branches and can easily cherry-pick features & big fixes): here, merges faster advantage. Other places care a lot about the individual commits and preserving commit history from dev/feature branches - here merges can hide some of that granularity, and rebases are a better fit. The latter is common for projects with one evergreen release branch without any concern about back-porting features or fixes to other, currently supported release branches; supporting versions N, N-1, and N-2 is common in enterprise software, with each having its own release branch or tag.

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

#97

Post by fallingsquirrel »

jjmarr wrote: post #78
fallingsquirrel wrote: post #47

Earlier quoted context omitted.

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

I didn't have to use git bisect. I looked at commit history directly and guessed what caused the regression. As we all test different parts of the microprocessor and the tagging system reflected those parts, I could rule stuff out by looking at git log --oneline. The commit messages were also required to be high quality and I could get a gut feeling about what stuff a commit would touch without looking at the code. >…

> the merge commit also wouldn't be tested

Why wouldn't it? This is the "not rocket science" rule of software engineering: every commit must pass the tests. There's no special exception for merge commits.

https://graydon2.dreamwidth.org/1597.html

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

#98

Post by lmm »

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

Earlier quoted context omitted.

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

WTF? If you keep the original history and regularly merge master into feature branches you're tracking people's actual edits as they worked on their feature, which is the most useful thing to have when bisecting, but you're also staying close to mainline during development. It's the best of both worlds.

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

#99

Post by lmm »

wakawaka28 wrote: post #91
lmm wrote: post #61

Earlier quoted context omitted.

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

The original history is usually a bunch of garbage. If you need more detail you can rebase as many commits as you like. More detailed history is sometimes a distinct problem. Imagine trying to bisect some spaghetti bowl of commits with merges to find the source of a recurring issue. It would be relatively nonsensical compared to a clean linear history. Clean history can exist with merges, but I think merging all over…

> If you need more detail you can rebase as many commits as you like.

You can't rebase to get back to the original commits, not without knowing what they are.

> Imagine trying to bisect some spaghetti bowl of commits with merges to find the source of a recurring issue.

I do it all the time (well, less so now that I work with a better team where those issues are pretty rare), it's easy, that's the whole point of the git bisect command.

> It would be relatively nonsensical compared to a clean linear history.

Rebased history is much harder to bisect because you often get long chain of commits that don't compile or are otherwise broken.

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

#100

Post by lmm »

nh2 wrote: post #76
lmm wrote: post #59

Earlier quoted context omitted.

bisect works much better with merge than it does with rebase (with rebase it's easy to end up with a long chain of commits that don't compile, so your automated bisect script doesn't work).

Of course all your commits need to compile and pass tests. It didn't even occur to me that anybody would permit that in their CI. If you check in commits that don't compile then you can't use automatic bisection effectively (it still does work if that happens rarely, thanks to automatic `git bisect skip`). Of course every non-building commit will make bisecting a merge history a pain even more, not sure why you think…

> Of course all your commits need to compile and pass tests.

> It didn't even occur to me that anybody would permit that in their CI.

How do you enforce it? Are you saying you make your CI compile and run tests for every single commit on a feature branch before allowing it to be merged? That takes a lot of time if you're doing the kind of small commits that make bisection most effective.

> Of course every non-building commit will make bisecting a merge history a pain even more, not sure why you think it to be better with merges than with linear history.

Because with rebase you're much more likely to get a long chain of commits that don't compile. E.g. imagine developer A adds a new feature and starts off by writing some code that calls some function, and meanwhile developer B renames that function in master. Then a while later developer A rebases onto master, fixes their compilation errors, and merges their feature branch in. All of the commits A did in between now don't compile, so you will "git bisect skip" all of them, and if your bisect lands somewhere in that chain of commits you have to do another round of bisection manually or something.

With merge, all of A's commits still compile and you can bisect through to the specific commit that caused the problem. (Maybe one or two isolated commits don't compile because they were never tested on CI, sure, but that's ok - git bisect skip handles them, it's only a problem if you have a long chain of non-compiling commits)

Post reply on HN