On Sat, Feb 18, 2023 at 4:17 AM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Thu, Feb 16, 2023 at 8:02 PM Alex Henrie <alexhenrie24@xxxxxxxxx> wrote: > > > > On Thu, Feb 16, 2023 at 5:31 AM Tao Klerks <tao@xxxxxxxxxx> wrote: > > > > > > 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> > > > > 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 :) ?
