From: Jacob Keller <jacob.keller@gmail.com>
Date: Thu, 01 Feb 2018 06:37:12 GMT
Subject: Re: [PATCH v2 00/10] rebase -i: offer to recreate merge commits
Message-ID: <CA+P7+xor7xf5WPSeT+p4cGiaCnAazGHFHg5ago=fWVe9d2sk+w@mail.gmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.1801311424270.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>

On Wed, Jan 31, 2018 at 5:29 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> I think I may want to introduce a bigger change, still. I forgot who
> exactly came up with the suggestion to use `merge -C <original-commit>
> <to-merge>` (I think it was Jake), and I reacted too forcefully in
> rejecting it.
>

I believe someone else suggested it, but I replied that I liked it.

> This design had been my original design in the Git garden shears, and I
> did not like it because it felt clunky and it also broke the style of
> <command> <commit>.
>

I agree it's a bit weird it breaks the style of "<command> <commit>",
but on some level merge does this anyways as it's the first one to
take more than one argument.

> But the longer I think about this, the more I come to the conclusion that
> I was wrong, and that the -C way is the way that leaves the door open to
> the pretty elegant `-c <commit>` (imitating `git commit`'s option to
> borrow the commit message from elsewhere but still allowing to edit it).
>

The other reason I liked this, is that it matches merge syntax on the
command line, so users don't need to learn a special new syntax for
the todo file.

> And it also leaves open the door to just write `merge <to-merge>` and have
> the sequencer come up with a default merge message that the user can then
> edit.

I like that we could completely forgo the -C and -c in order to allow
the normal default merge commit message that is auto generated as
well.

>
> I'll probably refrain from implementing support for -m because I do not
> want to implement the dequoting.
>

Yea, I don't think that is necessary either.

Thanks,
Jake

> Ciao,
> Dscho