On Sat, Dec 10, 2016 at 1:00 AM, Jeff King [off-list ref] wrote:
On Sat, Dec 10, 2016 at 09:49:13PM +1300, Chris Packham wrote:
quoted
quoted
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