git/list[1] front-page[2] threads[3] people[4] search[5] about
 

merge: do not create a signed tag merge under --ff-only option

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 6, 2012, 00:22 UTC
Message-ID
<7vmx8wdd57.fsf@alter.siamese.dyndns.org>
In-Reply-To
<7vd39vlbgj.fsf@alter.siamese.dyndns.org>

Starting at release v1.7.9, if you ask to merge a signed tag, "git merge" always creates a merge commit, even when the tag points at a commit that happens to be a descendant of your current commit.

Unfortunately, this interacts rather badly for people who use --ff-only to make sure that their branch is free of local developments. It used to be possible to say:

	$ git checkout -b frotz v1.7.9~30
        $ git merge --ff-only v1.7.9

and expect that the resulting tip of frotz branch matches v1.7.9^0 (aka the commit tagged as v1.7.9), but this fails with the updated Git with:

	fatal: Not possible to fast-forward, aborting.

because a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by fast forwarding.

We could teach users that now they have to do
	$ git merge --ff-only v1.7.9^0
but it is far more pleasant for users if we DWIMmed this ourselves.

When an integrator pulls in a topic from a lieutenant via a signed tag, even when the work done by the lieutenant happens to fast-forward, the integrator wants to have a merge record, so the integrator will not be asking for --ff-only when running "git pull" in such a case. Therefore, this change should not regress the support for the use case v1.7.9 wanted to add.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
  Junio C Hamano <gitster@pobox.com> writes:
    We could solve this in one of two ways. We could tell them to merge
    v3.2.3^0 instead. Or we could just go ahead and do that for them
    automatically ourselves.  I am inclined to say that we should unwrap
    the tag given from the command line when --ff-only was given, i.e. we
    do the latter.
  And it turns out that it is just a single-liner patch.
 builtin/merge.c  |    3 ++-
 t/t7600-merge.sh |   13 +++++++++++++
 2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 3a45172..b4fbc60 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1283,7 +1283,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
 			    sha1_to_hex(commit->object.sha1));
 		setenv(buf.buf, argv[i], 1);
 		strbuf_reset(&buf);
-		if (merge_remote_util(commit) &&
+		if (!fast_forward_only &&
+		    merge_remote_util(commit) &&
 		    merge_remote_util(commit)->obj &&
 		    merge_remote_util(commit)->obj->type == OBJ_TAG) {
 			option_edit = 1;
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 5d8c428..a598dfa 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -27,6 +27,7 @@ Testing basic merge operations/option parsing.
 '
 
 . ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-gpg.sh
 
 printf '%s\n' 1 2 3 4 5 6 7 8 9 >file
 printf '%s\n' '1 X' 2 3 4 5 6 7 8 9 >file.1
@@ -670,4 +671,16 @@ test_expect_success 'merge --no-ff --edit' '
 	test_cmp actual expected
 '
 
+test_expect_success GPG 'merge --ff-only tag' '
+	git reset --hard c0 &&
+	git commit --allow-empty -m "A newer commit" &&
+	git tag -s -m "A newer commit" signed &&
+	git reset --hard c0 &&
+
+	git merge --ff-only signed &&
+	git rev-parse signed^0 >expect &&
+	git rev-parse HEAD >actual &&
+	test_cmp actual expect
+'
+
 test_done
Previous: Junio C Hamano
Message 3 of 3 in “[1.7.9] usage regression when merging annotated tag objects”
  1. Bart TrojanowskiFeb 3, 2012
  2. Junio C HamanoFeb 3, 2012
  3. merge: do not create a signed tag merge under --ff-only optionJunio C Hamano, Feb 6, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.