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

Hi Jake,

On Thu, 8 Mar 2018, Jacob Keller wrote:

On Thu, Mar 8, 2018 at 3:20 AM, Phillip Wood [off-list ref] wrote:

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).

As to your concern: The ultimate commit hashes do not have to be known
until the merge commit is rebased. The current approach is to use labels
for them (`label <name>`), which Simply Works.

Ciao,
Dscho