Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Dscho,

On 11/03/2018 13:11, Johannes Schindelin wrote:

quoted

quoted

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)

Since the ultimate commit hashes of newly rebased commits would be
unknown at the time of writing the todo file, I'm not sure how this
would work to specify the parents?

I agree with Phillip's follow-up that the `pick <original-merge>` syntax
would pose a problem, but for different reasons: We already tried it, with
--preserve-merges, and it is just a really stupid syntax that does not
allow the user even to reorder commits. Or drop commits (except at the
very end of the todo list).

Hehe, please excuse me, but in the light of that other explicit (or 
not) parent mapping discussion[1], I would take a chance to be really 
sneaky here and say that being non-explicit "is just a really stupid 
syntax that does not allow the user even to reorder rebased merge 
parents. Or drop parents (except at the very end of the parent list)." ;)

[1] https://public-inbox.org/git/b329bb98-f9d6-3d51-2513-465aad2fa37a@gmail.com/