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

71–80 of 116 posts

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

#71

Post by _ugfj »

lmm wrote: post #66
_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.

and yet these fuckers downvoted my post without commenting where I am wrong

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

#72

Post by ajkjk »

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 frickin love rebase-only linear history. It just feels so clean. It's so much easier to understand what happened if you're just scanning the commit history.

I also don't know of any pain to it, though. It's just simple and easy and clean.

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

#73

Post by mplanchard »

PaulDavisThe1st wrote: post #37
wakawaka28 wrote: post #33

Earlier quoted context omitted.

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.

If you accidentally record an incorrect resolution, you can also run `git rerere clear` to clear the cache, or `git rere forget ` to forget resolutions just for a particular file.

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

#74

Post by mplanchard »

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?

I generally just enable the above config, which uses it automatically when doing rebases. So, if I’m rebasing a bunch of commits, and I’ve already resolved a set of conflicts once, it just uses that resolution again.

If you want to have it forget a recorded resolution, for example because you messed something up, there are commands for that, but I use them very seldomly.

I’ve never run into any particular pitfalls to speak of. I mostly just turn it on and forget it’s there. You can still always go back in time with the reflog if needed.

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

#75

Post by nh2 »

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?

> Any given snapshot has a linear history

Not sure what you mean. The key thing of merges is that they... merge... two histories.

A git history graph tool shows that clearly then.

A bisection has to choose whether to go left or right.

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

#76

Post by nh2 »

lmm wrote: post #59
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.

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 it to be better with merges than with linear history.

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

#77

Post by PaulDavisThe1st »

mplanchard wrote: post #73
PaulDavisThe1st wrote: post #37

Earlier quoted context omitted.

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.

If you accidentally record an incorrect resolution, you can also run `git rerere clear` to clear the cache, or `git rere forget ` to forget resolutions just for a particular file.

Yeah, I learned about this last weekend, after mistakenly trying to rebase a repo where we generally merge.

I don't think that rerere offers fine grained enough control over "forgetting". What I needed (until I realized my mistake) was a way to clear any memory of a resolution for the current conflict in path.

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

#78

Post by jjmarr »

fallingsquirrel wrote: post #47
jjmarr wrote: post #39

Earlier quoted context omitted.

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

> 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 rebase? You threw away your only means of finding out when you rewrote history.

This happened semi-frequently. We were using Gerrit and had every version of a rebased commit visible together. When code that fails automated testing got submitted, it immediately caused CI failures for everyone. It took an hour for someone unfamiliar with the code to look at the timestamp the failures began, find the commit that caused the failures, and revert it.

I don't see how this would be meaningfully different in a merge scenario, because the merge commit also wouldn't be tested.

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

#79

Post by imiric »

lmm wrote: post #56
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…

The fears are legitimate. Both rebase and force-push can lose data in some circumstances, which merge and push cannot. Yes, there are strategies which, if followed perfectly, allow one to avoid losing data when doing rebase and/or force-push. But those strategies are not simple to describe, especially to newcomers, and in practice people make mistakes; all else being equal, an inherently safe workflow is better.

> The fears are legitimate.

They're really not.

First of all, no data is really lost with Git. Commits can be recovered from the reflog if they haven't been garbage collected, and there are ways of recovering anything on GitHub as well[1], even if it technically shouldn't be the case.

But this aside, data loss is circumstantial, like you say. I've heard the idea that force-pushing in general is harmful, when it's really not if you're working solo or on an isolated branch. Rebasing and force-pushing are just different tools in the toolbox.

In general, my objection is to the practice of describing any software as "dangerous". It creates an air of intimidation that prevents people from using the tools to their full extent, which when spread can popularize wrong practices among new users as well. This is why you see the person in the article claiming that they've always been a "merger", having a false dilemma between merging and rebasing, and describing their solution as "fearless". This line of thinking is also commonly associated with the command line and Linux itself, and is just harmful.

Instead, users should be educated on what the software does, which does require having comprehensive UIs and documentation, and designing the software with sane defaults, fail-safes, and ways to undo any action. Git doesn't do a great job at all of these, but overall it's not so bad either. What really hurts users is spreading the wrong kind of ideas, though.

[1]: https://neodyme.io/en/blog/github_secrets/

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

#80

Post by globular-toast »

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

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

You should do the squashing/fixing regularly too, not once right at the end. Again, rebasing gives you the chance to fix these things as soon as it happens, rather than deal with one massive merge conflict at the end of a long running feature branch.
Post reply on HN