Re: Why does "merge --continue" expect no arguments?

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>>>     $ git merge --continue
>>>     fatal: There is no merge in progress (MERGE_HEAD missing).
>>>
>>> FWIW I prefer and use it for that reason, i.e. it's useful for scripting
>>> to use these "stateful" commands when we're in some sort of rebase/merge
>>> "sequence" since it's an extra layer of sanity checking.
>>
>> There is no additional safety afforded by that, though.  There is no
>> reason why one would even try to say "merge --continue" without
>> doing any merge to begin with.
>>
>> The "merge --continue" not taking any pathspec is a bit of safety,
>> but even there, "commit" already has its own safety to reject
>> pathspec when it notices that it is concluding a conflicted "merge",
>> so "merge --continue" is not necessary for additional safety there,
>> either.
>
> The reason would be that you're confused about what state you're in.
>
> I've had that a few times, so I prefer it over "git commit", so I daresy
> someone less experienced in using git could and would benefit from it as
> well.

One can be lost and think that one is in the middle of "git merge"
when in reality there is no merge going on.  Or one can be lost and
confused the other way around, i.e. one thinks one is about to
finish the work one has been doing and conclude in a single parent
commit when in reality that one has done all that is necessary to
whip the working tree and the index into a state good enough to
record as a commit object.

In the former case, saying "git merge --continue", instead of "git
commit" may STOP oneself from proceeding, but then what?

Step back and think the other confusion first.  Saying "git commit",
instead of "git merge --continue", would allow one to record the
merge commit.  It opens an editor, its first line of the log message
would say "Merge blah into bar", the comment section tells you that
you are committing a merge.  It even prevents one from making a
partial commit with "git commit <pathspec>" or screw up the state
with "git commit --amend".  It is totally safe.

Now back to the former case.  You thought your working tree contents
and the index was good enough shape to say "git merge --continue",
but the command refuses because you were not merging.  I have a
suspicion that the message I am responding is a straw-man not worth
I should spend more time on, and if you are truly lost you would
either (1) look at the command line prompt or (2) run "git status"
to re-orient yourself before doing anything drastic like running the
"git merge --continue" command, but hypothetically, if you are lost
between merge and commit yet you are confident enough that your
working tree state and the index is worth recording in a commit
anyway, after a mistaken "git merge --continue" stops you from doing
so, I expect that you would "git commit" to record that tree into a
commit anyway, no?

So, I do agree there would be cases where a user is lost and does
not know what state the working tree s/he just came back to is in,
but "git merge --continue" is a mechanism that gives great help to
such a user.  "git status" may well be such a command, but "git
merge --continue" is not, and training users to use the latter
certainly is a wrong direction to go in.

By the way, you are wasting your time by repeating what you already
said and given an answer that the line of reasoning does not make
much sense.  Unless your goal is to be the one that sends the last
message to a discussion thread, that is.  You can respond to this
message without anything new and I promise that I won't repeat what
has been said already, in such a case.  So you'll be the last one to
utter in this thread then ;-)

You can share a new perspective, of course, in which case I may say
"Light! thanks".