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

From: Jacob Keller <jacob.keller@gmail.com>
Date: Dec 10, 2016, 10:58 UTC
Message-ID: <CA+P7+xpwzrbuOb_YzyCatvkhHxEAhP1LVWrnP-yDX=-zmL5uhQ@mail.gmail.com>
In-Reply-To: <20161210090054.w6qhmszcjkatjhm5@sigill.intra.peff.net>

On Sat, Dec 10, 2016 at 1:00 AM, Jeff King <peff@peff.net> wrote:

Show 21 quoted lines

> On Sat, Dec 10, 2016 at 09:49:13PM +1300, Chris Packham wrote:
>
>> > 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.
>
> I'd be against giving it a subtly-different name. It's just going to
> frustrate people who cannot remember when to use "--conclude" and when
> it is "--continue". The strength of the proposal, IMHO, is that it
> abstracts the idea of "go on to the next thing or finish" across many
> commands.
>
> -Peff

Agreed. I think "continue" makes sense as the command had to "stop" the merge so you could give input, and then you tell git to "continue" which also happens to mean "finish the merge" and yes it may not be 100% accurate, but the point of adding "git merge --continue" is that it simplifies the mental model between rebase, cherry-pick, and merge, all of which stop and ask the user to resolve a conflict before "continue"ing and finalizing that resolution.

Thanks, Jake