On Fri, Feb 17, 2023 at 4:15 AM Alex Henrie <alexhenrie24@xxxxxxxxx> wrote: > > 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`. Heh, what would it take to convince you there is such an effort? :) - sparse and minor as my contributions are, I certainly believe that is a "natural" effort that I will do what I can to support. > That seems like an achievable goal, and I don't think it > would take multiple years, maybe one year at the most. My estimate is based on the observation that there are still, several years after --rebase-merges was introduced, git GUIs that don't handle it right - eg Jetbrains IDEA: https://youtrack.jetbrains.com/issue/IDEA-232160/Rebase-merges-is-not-properly-supported This kind of functionality change should be slow, not because it's a huge amount of work, but more because it takes time for the entire ecosystem to adapt. Git releases basically-monthly, but many of the systems that users use git with release far less often; similarly, it's helpful to users who use a mix of current and older systems (I'm looking at you, CentOS 7) for the introduction and recommendation of a behavior change to come *long* before its defaulting. > The process > would look something like this: > > 1. Add a --no-rebase-merges option to `git rebase`. > > 2. Add a rebase.merges config option. Yes and yes! I alluded to this in https://lore.kernel.org/git/CAPMMpoj6E-85a59EaHD2aR_oKA=_u78qRV+wp8mqXkR39KctmA@xxxxxxxxxxxxxx/ but didn't feel I'd likely to make a solid change along these lines. > > 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. > Makes sense to me! > 4. Change the `git pull` advice to recommend --rebase=merges and > pull.rebase=merges. > I'm not sure why this would be step 4 - I would (and did try to) make it step 1 :) > 5. Wait a couple of releases. > As I noted above, I believe it should be far more than a couple. > 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`. > Makes sense to me! > 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. > I'm sold, except insofar as I think the right approach is to move step 4 to be the first :)
