Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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".
