On Fri, Jun 06, 2025 at 11:00:10PM +0200, Edmundo Carmona Antoranz wrote: > So, I sat down and wrote rebase--, a pygit2-based script (yeah, I > know, I am a shameless cheater :-)) that _attempts_ to run rebases and > take advantage of previous merge commits to try and avoid asking the > user to redo conflicts **if they are easy to deal with**. [...] That's cool, but I hope not to ever benefit from it because I prefer rebase-only workflows -- look ma'! no merges! :) I use a different approach which is to use something like a bisection to find the first upstream commit where a conflict arises -if any- so I can resolve the conflict there where the information about what changed upstream is most relevant. This is the script I use: https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 In the comments you'll find links to several similar tools: https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297?permalink_comment_id=4659501#gistcomment-4659501 git-imerge in particular is real pithy about what it does for you: | Reduce the pain of resolving merge conflicts to its unavoidable | minimum, by finding and presenting the smallest possible conflicts: | those between the changes introduced by one commit from each branch. But yeah, if you have a codebase that merged from upstream and now you want to rebase it, then using the conflict resolutions from the merges makes sense. It's just I hope dearly to avoid merges, and IMO more people should do that too. I get that this message risks starting a flame war :( but it's not my intent to start a flame war. And I get that there are cases where you have to merge features from multiple upstreams and cherry-picking gets tricky enough that merging becomes the only viable option. But if you have to track multiple upstreams and you can help it you'll be much better off cherry-picking than merging, and in all other cases just follow a rebase workflow. This sort of problem (rebasing or merging across massively many commits upstream) is the sort where rebase workflows shine precisely because your commits are "always on top", therefore they are always easily identified as the commits you want to "move" to be based on a new upstream HEAD. With merge workflows you simply can't get the information you need to resolve conflicts, and the best you can do is "see how I did it before", but with rebase workflows and conflict bisection you get to have the most pristine conflicts -- the ones where you have the most local and upstream information available to help you resolve the conflict. Nico --
