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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

On 2024-10-03 at 19:06:28, 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.

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.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]