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

[Jeff King <peff@peff.net>]

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

> 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