> >
> > For now I would say the subtleties in that conversation really make me
> > lean towards the following:
> >
> > - "git <thing> --continue" is, for most users in most cases, the right
> > thing to do. It's what "git status" recommends and will practically
> > never do anything surprising (?).
>
> I was actually surprised to discover that `git status` does not recommend
> `git merge --continue`: it recommends `git commit`.

> > - However, it may not always be exactly what you *want*---and you'll
> > usually know when you want to go "outside" the normal sequencer and
> > commit directly (because you'll have understood some nuanced details
> > about what can happen).
> >
> > For merge it may be the case that they're the same, I suppose (I'm
> > genuinely not sure), but I would prefer to simplify folks' paths by
> > recommending one of the few uniform interfaces we have :)
>
> The only other thing that gives me pause about recommending folks
> `git merge --continue` too strongly is that as we know Git users are slow to
> change their habits, and we don't want to confuse anyone. If someone is
> currently using `git commit` I want to know that they can keep doing
> it the same way with no worries.
>
> Maybe if we change `git status` to recommend `git merge --continue`,
> and we think there are no real advantages to using `git commit` instead
> of `git merge --continue`, then we could say something like this:
>
>   NOTE: `git commit` is an older alternative to `git merge --continue`.
>   You can use either one after resolving a `git merge`.