Re: Request for adding a "one-shot" rebase strategy where conflicts are only resolved once

From: Jeff King <peff@peff.net>
Date: Oct 3, 2024, 21:30 UTC
Message-ID: <20241003213029.GB12763@coredump.intra.peff.net>
In-Reply-To: <CAD9n_qgBPDQKF=ZEQ6SWvDCmcUXZvz33zSoHFQSwHmQPWS4z_Q@mail.gmail.com>

On Thu, Oct 03, 2024 at 10:36:28PM +0330, Alireza wrote:

Show 9 quoted lines

> Sometimes a clean merge is possible but with a rebase, in-between
> commits may raise conflicts in which case a conflict must be resolved
> for each commit individually, which is not quite productive and at the
> end wouldn't add so much in how the resulting history looks like.
> 
> With a "one-shot" rebase, a conflict (if any) is made based on the
> latest revision, then in-between commits approximated based on that
> resolution. This way the history can be roughly preserved with the
> same amount of effort while still using a rebase rather than merge.

I'm not quite sure how you'd approximate those fixes in the general case. You could leave the conflict markers in place, making it obvious that the intermediate state is broken, and then replace it all at the end.

That does make me question what the value is in rebasing instead of simply merging, though.

You might want to peek at git-imerge (which also does rebasing, despite the name):

  https://github.com/mhagger/git-imerge

I think in a sense it is the _opposite_ of what you are asking for, in that it breaks the merge down into its smallest parts by finding the conflicting pairs. But I wonder if you'd find the conflicts it produces more pleasant to work with, or more tedious.

-Peff