All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Daniel Vicarel <shundra8820@gmail.com>, git@vger.kernel.org
Subject: Re: Why does "merge --continue" expect no arguments?
Date: Mon, 27 Dec 2021 00:31:07 +0100	[thread overview]
Message-ID: <211227.868rw7exvi.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqk0ft5toy.fsf@gitster.g>


On Fri, Dec 24 2021, Junio C Hamano wrote:

> Æ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 &&

  reply	other threads:[~2021-12-26 23:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21 14:50 Why does "merge --continue" expect no arguments? Daniel Vicarel
2021-12-21 17:13 ` Junio C Hamano
2021-12-21 17:51   ` Daniel Vicarel
2021-12-21 17:54     ` Daniel Vicarel
2021-12-22  6:20     ` Junio C Hamano
2021-12-21 17:57   ` Philip Oakley
2021-12-24 17:08   ` Ævar Arnfjörð Bjarmason
2021-12-25  2:01     ` Junio C Hamano
2021-12-26 23:31       ` Ævar Arnfjörð Bjarmason [this message]
2021-12-27 19:29         ` Junio C Hamano
     [not found] ` <CAFOYHZC0r35mfOVUExHsBP5=URKFAt_wDTZ51pTc=XkXyogqKQ@mail.gmail.com>
2021-12-23  6:07   ` Daniel Vicarel
2021-12-23 18:35     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=211227.868rw7exvi.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=shundra8820@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.