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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 11, 2018, 12:11 UTC
Message-ID: <nycvar.QRO.7.76.6.1803111308320.20700@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <CA+P7+xoOVzxnmZN893ND4+55=OhtrE-gt7jRhtxoOUL=G_CrgA@mail.gmail.com>

Hi Jake,

On Thu, 8 Mar 2018, Jacob Keller wrote:

Show 14 quoted lines

> On Thu, Mar 8, 2018 at 3:20 AM, Phillip Wood <phillip.wood@talktalk.net> wrote:
> > 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