Re: RFC - rebase--

[Nico Williams <nico@cryptonector.com>]

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