On Tue, Feb 28, 2023 at 7:13 AM Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > > On Thu, Feb 16, 2023 at 7:33 AM Tao Klerks <tao@xxxxxxxxxx> wrote: > > On Thu, Feb 16, 2023 at 4:22 AM Alex Henrie <alexhenrie24@xxxxxxxxx> wrote: > > > > Now, this is not to say that there's no room for improvement. I like > > > the rebase=merges option and I wish everyone knew about it because > > > there are situations where it really is the best option. I suggest > > > leaving the existing text alone, but adding an additional paragraph, > > > something like: > > > > > > Note that --rebase or pull.rebase=true will drop existing merge > > > commits and rebase all of the commits from all of the merged branches. > > > If you want to rebase but preserve existing merge commits, use > > > --rebase=merges or pull.rebase=merges instead. > > > > My primary motivation with this pull request is to reduce the > > incidences, out there in the world, of people copy-pasting "git config > > pull.rebase true" into their command-line, and causing themselves > > major headaches days or weeks later. The "--rebase=interactive" part > > is secondary (to my concerns), because it's much less copy-pastable. > > That's because the whole approach to the pull.rebase configuration is > wrong. I explained why multiple times in countless discussions and git > developers did not listen. > > What we need is a pull.mode configuration that is *orthogonal* to > pull.rebase, then everything just works. > > For example, you could have this configuration. > > git config pull.mode merge > git config pull.rebase merges > > Then doing `git pull --rebase` would do a merges rebase. > > This is not possible with the current approach, which I objected to. > > Then there's no problem with telling the users to do pull.mode=rebase > (or whatever), since that doesn't override pull.rebase=merges. > > I programmed and explained this precise interaction with rebase=merges > more than two years ago [1], but nobody listened. For an example of > how such configuration would look like, see the patches I just sent > [2]. > > Cheers. > > [1] https://lore.kernel.org/git/20201218211026.1937168-14-felipe.contreras@xxxxxxxxx/ > [2] https://lore.kernel.org/git/20230228140236.4175835-1-felipe.contreras@xxxxxxxxx/T/#t I think everybody agrees that the current situation is kind of a mess. For better or for worse, there was no consensus to get away from the current set of config options and introduce something more straightforward, so we keep making incremental evolutionary changes within the current framework. I didn't include it in my list of things to do, but your email made me realize that the problem with `git pull` not being able to do an interactive rebase that rebases merge commits is also something that needs to be fixed before flipping on "rebase merges" by default. If we add that to the list, I guess it would be step 2.25. It's going to be confusing if `git pull -r` rebases merges but `git pull -ri` does not. One way to solve that would be to make -ri/--rebase=interactive on the command line work with pull.rebase=merges instead of overriding it, and add a separate --(no-)rebase-merges command line option for if the user really does want to override it. On top of that, either before or at the same time as when the default behavior of `git pull --rebase` changes to rebase merges, the behavior of branch.autoSetupRebase needs to change to match. -Alex
