On Fri, Dec 09, 2016 at 11:16:52AM -0800, Junio C Hamano wrote: > > 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.
No, I think your reasoning makes sense. But I also think we've already choosen to have "--continue" mean "conclude the current, and continue if there is anything left" in other contexts (e.g., a single-item cherry-pick). It's more vague, but I think it keeps the user's mental model simpler if we provide a standard set of options for multi-step commands (e.g., always "--continue/--abort/--skip", though there are some like merge that omit "--skip" if it does not make sense). -Peff
