Re: Why does "merge --continue" expect no arguments?
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Dec 26, 2021, 23:31 UTC
- Message-ID
- <211227.868rw7exvi.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <xmqqk0ft5toy.fsf@gitster.g>
On Fri, Dec 24 2021, Junio C Hamano wrote:
Show 32 quoted lines
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > >> On Tue, Dec 21 2021, Junio C Hamano wrote: >> >>> Or we could throw in another >>> >>> * document more clearly that "merge --continue" is a mere synonym >>> for, and hint that there is no reason to favor it over, "git >>> commit". >> >> But it's not: >> >> $ git add foo >> $ git commit -v >> hint: Waiting for your editor to close the file.[...] >> ^C >> $ 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.
Usually because my "__git_ps1" and a subsequent "git status" shows one state, so I'll want to continue the merge, but forgot that I did so in another terminal tab already, and the real state of the repository might have moved on to the index being prepared for a non-merge commit.
For "rebase --continue" we change the reflog entry from "rebase (pick)" to "rebase (continue)". Any reason we wouldn't do the same for "merge --continue"?:
diff --git a/builtin/merge.c b/builtin/merge.c index 5f0476b0b76..51ef8ca36d0 100644 --- a/builtin/merge.c +++ b/builtin/merge.c @@ -1358,6 +1358,10 @@ int cmd_merge(int argc, const char **argv, const char *prefix) if (!file_exists(git_path_merge_head(the_repository))) die(_("There is no merge in progress (MERGE_HEAD missing).")); + strbuf_addstr(&buf, "merge (continue)"); + setenv("GIT_REFLOG_ACTION", buf.buf, 0); + strbuf_reset(&buf); + /* Invoke 'git commit' */ ret = cmd_commit(nargc, nargv, prefix); goto done; diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh index c773e30b3fa..7a180f571b7 100755 --- a/t/t7600-merge.sh +++ b/t/t7600-merge.sh @@ -772,6 +772,8 @@ test_expect_success 'completed merge (git merge --continue) with --no-commit and git stash show -p MERGE_AUTOSTASH >actual && test_cmp expect actual && git merge --continue 2>err && + git reflog -1 >reflog && + grep -F "merge (continue)" reflog && test_i18ngrep "Applied autostash." err && git show HEAD:file >merge-result && test_cmp result.1-5 merge-result &&