On 14/03/2018 15:24, Sergey Organov wrote: > > > > Second side note: if we can fast-forward, currently we prefer that, and I > > > think we should keep that behavior with -R, too. > > > > I agree. > > I'm admittedly somewhat lost in the discussion, but are you talking > fast-forward on _rebasing_ existing merge? Where would it go in any of > the suggested algorithms of rebasing and why? > > I readily see how it can break merges. E.g., any "git merge --ff-only > --no-ff" merge will magically disappear. So, even if somehow supported, > fast-forward should not be performed by default during _rebasing_ of a > merge. Hmm, now that you brought this up, I can only agree, of course. What I had in my mind was more similar to "no-rebase-cousins", like if we can get away without actually rebasing the merge but still using the original one, do it. But I guess that`s not what Johannes originally asked about. This is another definitive difference between rebasing (`pick`?) and recreating (`merge`) a merge commit - in the case where we`re rebasing, of course it doesn`t make sense to drop commit this time (due to fast-forward). This does make sense in recreating the merge (only). > > > If the user wants to force a new merge, they simply remove that -R > > > flag. And this sounds wrong now, too, because we actually have _three_ possible behaviors here - (1) rebase merge commit, which should always do what its told (so no fast-forwarding, otherwise the whole concept of rebasing a merge commit doesn`t make sense), and recreate merge commit, which should (2) by default use fast-forward where possible (or whatever the settings say), but (3) also be possible to force a new merge as well (through standard `--no-ff`, I guess, or something). > Alternatively, they'd replace 'pick' with 'merge', as they already do > for other actions. "A plurality is not to be posited without necessity". > > Please, _please_, don't use 'merge' command to 'pick' merge commits! > It's utterly confusing! I agree here, as previously discussed[1], but let`s hear Johannes. > Thinking about it I've got an idea that what we actually need is > --no-flatten flag that, when used alone, will just tell "git rebase" to > stop flattening history, and which will be implicitly imposed by > --recreate-merges (and --preserve-merges). > > Then the only thing the --recreate-merges will tune is to put 'merge' > directives into the todo list for merge commits, exactly according to > what its name suggests, while the default behavior will be to put 'pick' > with suitable syntax into the todo. And arguments to the > --recreate-merge will specify additional options for the 'merge' > directive, obviously. This seem to basically boil down to what I mentioned previously[2] through use of new `--rebase-merges` alongside `--recreate-merges`, just that you named it `--no-flatten` here, but the point is the same - and not something Johannes liked, "polluting" rebase option space further. I would agree with him, and settling onto `--rebase-merges` _instead_ of `--recreate-merges` seems as a more appropriate name, indeed, now that default behavior is actually merge commit rebasing and not recreating (recreating still being possible through user editing the todo list). Now, the only thing left seems to be agreeing on actual command to use to rebase the merge commit, to `pick` it, so to say... ;) Regards, Buga [1] https://public-inbox.org/git/77b695d0-7564-80d7-d9e6-70a531e66eda@xxxxxxxxx/ [2] https://public-inbox.org/git/b329bb98-f9d6-3d51-2513-465aad2fa37a@xxxxxxxxx/
