On 08/03/2018 13:16, Phillip Wood wrote: > > > Side note: I wonder whether we really need to perform the additional check > > that ensures that the <merge-head> refers to the rewritten version of the > > original merge commit's parent. > > > > [...] > > Oops that was referring to the first side note. I think fast forwarding > is a good idea. I'm not so sure about checking that <merge-head> refers > to the rewritten version of the original merge commit's parent any more > though. Having thought some more, I think we would want to allow the > user to rearrange a topic branch that is the parent of a merge and that > would require allowing a different parent as the old parent could be > dropped or swapped with another commit in the branch. I can't think of a > way to mechanically check that the new parent is 'somehow derived from' > the old one.
Exactly, we must not depend on exact parent commits, but on parent "branches" (so to say). And that is why I think explicit mapping would be pretty helpful (if not the only approach). > > I did wonder about using 'pick <original-merge>' for rebasing merges and > > keeping 'merge ...' for recreating them but I'm not sure if that is a > > good idea. It has the advantage that the user cannot specify the wrong > > parents for the merge to be rebased as 'git rebase' would work out if > > the parents have been rebased, but maybe it's a bit magical to use pick > > for merge commits. Also there isn't such a simple way for the user to go > > from 'rabase this merge' to 'recreate this merge' as they'd have to > > write the whole merge line themselves (though I guess something like > > emacs' git-rebase.el would be able to help with that) > > Scrub that, it is too magical and I don't think it would work with > rearranged commits - it's making the --preserve-merges mistake all over > again. It's a shame to have 'merge' mean 'recreate the merge' and > 'rebase the merge' but I don't think there is an easy way round that. I actually like `pick` for _rebasing_ merge commits, as `pick` is already used for rebasing non-merge commits, too, so it feels natural. Then `merge` is left to do what it is meant for - merging (or "recreate the merge", in the given context). I tried to outline a possible user interface in that other reply[1], elaborating it a bit, too, Regards, Buga [1] https://public-inbox.org/git/f3872fb9-01bc-b2f1-aee9-cfc0e4db7...@gmail.com/
