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

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.

On Thu, Oct 3, 2024, at 21:06, Alireza wrote:

How would this compare to using git-rerere(1)?

As far as I know, rerere remembera an exact resolution, but with rebase you may have to deal with different conflicts for each commit This makes that completely irrelevant, to elaborate there's basically two possibility: (1) a clean merge is possible but individual commits may conflict (2) a clean merge is not possible which means there may be conflicts at some point onward

This only creates one conflict off of the latest revision (same as git merge) or skip if a clean merge is possible Then each commit is reconstructed based on that resolution so there's no back and forth.

Hope this helps.

Thanks,

On Thu, Oct 3, 2024 at 11:45 PM Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote:

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

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

On 2024-10-03 at 19:06:28, Alireza wrote:

People actually use rebase in some cases because they want conflicts that they won't get with a merge. For example, for a merge between `feature` and `main`, if `main` adds a change A, and `feature` adds a change B that would conflict with A and and removes B, then with a merge, the merge is clean and only A is included. However, with a rebase, there's a conflict, and for some people that is absolutely desired. We've gotten complaints on the list that merges don't have that behaviour (merges consider only the two heads and the merge base).

I would also point out that your proposed one-shot rebase will make reviewing commit by commit much harder since it won't contain the exact changes that the author intended in each commit. I frequently write series at work and on the Git list that have multiple commits, each of which is independent and logically bisectable, so that reviewers can have more confidence in my changes and understand them better. This feature would be confusing to the reviewers, and it might break bisectability since the code might not build and pass all the tests at each point.

I am also somewhat doubtful that we can come up with a good approximation algorithm for resolving conflicts in this way. I'm thinking of some rather tricky conflicts I've had to solve in the past and how pretty much any approximation I can imagine would have ended up making things worse.

Perhaps if you can propose an algorithm for doing this, people can provide you more concrete feedback on your approach and its advantages and disadvantages, outside of the more philosophical objections I've mentioned above.