Re: Any interest in 'git merge --continue' as a command

[Chris Packham <judge.packham@gmail.com>]

On Sat, Dec 10, 2016 at 8:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>>> They knew about git rebase --continue (and git am and git cherry-pick)
>>> but they were unsure how to "continue" a merge (it didn't help that
>>> the advice saying to use 'git commit' was scrolling off the top of the
>>> terminal). I know that using 'git commit' has been the standard way to
>>> complete a merge but given other commands have a --continue should
>>> merge have it as well?
>>
>> It seems like that would be in line with 35d2fffdb (Provide 'git merge
>> --abort' as a synonym to 'git reset --merge', 2010-11-09), whose stated
>> goal was providing consistency with other multi-command operations.
>>
>> I assume it would _just_ run a vanilla "git commit", and not try to do
>> any trickery with updating the index (which could be disastrous).
>
> If we were to have "merge --continue", I agree that it would be the
> logical implementation.
>
> There is nothing to "continue" in a stopped merge where Git asked
> for help from the user, and because of that, I view the final "git
> commit" as "concluding the merge", not "continuing".  "continue"
> makes quite a lot of sense with rebase and cherry-pick A..B that
> stopped; it concludes the current step and let it continue to
> process the remainder.  So from that point of view, it somewhat
> feels strange to call it "merge --continue", but it probably is just
> me.
>

Yeah I did think that --continue wasn't quite the right word. git
merge --conclude would probably be the most accurate.