Hacker News Reader

Comment by sensanaty | Hacker News Reader

I use it often as well, but if I'm rebasing more than a handful of commits it becomes very annoying and confusing if there's a conflict. For example, I often run into the situation where I'll get a conflict, I resolve that conflict on the first rebase step, but then the same conflict keeps popping up. Where did the resolution I just did disappear to? Why do I have to keep redoing the resolution?

View on HN

Yep. I think that's a "normal" feature of how conflict resolution during rebases work: To perform your rebase, git merges each of the original commits into your new history, in turn. If one if those commits has a change that causes a conflict, the subsequent commits will likely have the same change and cause that same conflict again. And because your resolution is only for one commit, it will be "forgotten" in the next merge.

I think "git rerere" was built as a sort of bandaid for this. It doesn't really fix the problem but it at least makes it less annoying. (Haven't used it yet though)

https://git-scm.com/book/en/v2/Git-Tools-Rerere

It's because git replays your commits one at a time on top of a new commit; so if you resolve a conflict but then your next commits also touches the same code, the intent is ambiguous to git and it asks for your help with the conflict.

Wsc891 https://news.ycombinator.com/user?id=wsc981 has a good resolution for this in the comment directly above: 1) rebase -i onto your own history and squash 2) rebase onto the new branch.

Reply on news.ycombinator.com