On Sat, Dec 10, 2016 at 8:16 AM, Junio C Hamano [off-list ref] wrote:
Jeff King [off-list ref] writes:
quoted
quoted
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.