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: 1. Add a --no-rebase-merges option to `git rebase`. 2. Add a rebase.merges config option. 3. Add a warning to `git rebase` that appears if rebase.merges is unset and neither --rebase-merges nor --no-rebase-merges is given. The warning would advise the user that the default behavior of `git rebase` will change in a future release and suggest setting rebase.merges=no-rebase-cousins to get the new behavior now. 4. Change the `git pull` advice to recommend --rebase=merges and pull.rebase=merges. 5. Wait a couple of releases. 6. Change the default behavior of `git rebase` to `git rebase --rebase-merges` and the default behavior of `git pull --rebase` to `git pull --rebase=merges`. At the same time, remove the warning from `git rebase`. The old `git pull` behavior would still be available as `git pull --rebase=true`. 7. Change the `git pull` advice to recommend the short and simple --rebase option again (leaving the recommendation of pull.rebase=merges for the config option). Does that sound reasonable? I think I could lend a hand with steps 1-3. -Alex
