Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer "merges" vs "true"

On Sat, Feb 18, 2023 at 4:17 AM Elijah Newren [off-list ref] wrote:

On Thu, Feb 16, 2023 at 8:02 PM Alex Henrie [off-list ref] wrote:

quoted

On Thu, Feb 16, 2023 at 5:31 AM Tao Klerks [off-list ref] wrote:

quoted

If there's an appetite for it, I would love to contribute to a
multi-year adventure to change git's behavior, little by little, until
the behavior of "rebase=merges" is the default, and the old behavior
becomes a different option like
"rebase=copy-merged-commits-to-flatten"

I know you had a lot to say in your last email, but I'd like to focus
on this point. I would be OK with the proposed patch if it were part
of a larger effort to make --rebase-merges the default behavior of
`git rebase`. That seems like an achievable goal, and I don't think it
would take multiple years, maybe one year at the most. The process
would look something like this:

<SNIP>

quoted

Does that sound reasonable? I think I could lend a hand with steps 1-3.

One concern I have is that "--rebase-merges" itself has negative user
surprises in store.  In particular, "--rebase-merges", despite its
name, does not rebase merges.  It uses the existing author & commit
message info, but otherwise just discards the existing merge and
creates a new one.  Any information it contained about fixing
conflicts, or making adjustments to make the two branches work
together, is summarily and silently discarded.

My personal opinion would be adding such a capability should be step
2.5 in your list, though I suspect that would make Tao unhappy (it's a
non-trivial amount of work, unlike the other steps in your list).

I apologize for my ignorance here, but I'm not sure how this "does not
rebase merges" concern overlaps with the "pull.rebase" context I'm
most specifically concerned about.

I would have assumed that when merge commits are "dropped", as results
from the current "pull.rebase=true" option in the pull conflict
advice, any merge resolution information is *also* dropped - so there
is no loss to the user here in advising the use of
"pull.rebase=merges" instead.

Is your concern about the "pull.rebase=merges" advice change, or more
about the broader "let's encourage users to more explicitly choose
between traditional merge-dropping rebase and rebase-merges" change
Alex is advocating for as a precondition to "my" change :) ?