Ævar Arnfjörð Bjarmason [off-list ref] writes:
On Tue, Dec 21 2021, Junio C Hamano wrote:
quoted
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.
On Fri, Dec 24 2021, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
On Tue, Dec 21 2021, Junio C Hamano wrote:
quoted
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 &&