{"thread":{"id":"29538","subject":"[1.7.9] usage regression when merging annotated tag objects","startedAt":"2012-02-03T23:08:06Z","lastAt":"2012-02-06T00:22:12Z","messageCount":3,"participants":["Bart Trojanowski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183783","messageId":"CADeLxZTsq1M5oEb1u5Oqfxq3dYXL6E_uN9bXaTqaOZiA0fgdJQ@mail.gmail.com","threadId":"29538","inReplyTo":null,"subject":"[1.7.9] usage regression when merging annotated tag objects","fromName":"Bart Trojanowski","fromEmail":"bart@jukie.ca","sentAt":"2012-02-03T23:08:06Z","receivedAt":"2012-02-03T23:08:06Z","isPatch":false,"sender":{"key":"bart@jukie.ca","avatar":null},"body":"I recently started using git 1.7.9.  Earlier today GregKH released a stable\nkernel update and I tried my tried and true procedure using 'git merge\n--ff-only v3.2.3'.  I was a bit surprised with the results.\n\nThere are two tags I am toying with...\n\n69bade0 is v3.2.3\n3499d64 is v3.2.2\n\nAnd here is where we start...\n\n$ git describe\nv3.2.2\n\n$ git merge-base v3.2.2 v3.2.3 | xargs git describe\nv3.2.2\n\n(it is thus eligible for a fast-forward)\n\nFinally, the strangeness...\n\n$ git merge --ff-only v3.2.3\nfatal: Not possible to fast-forward, aborting.\n\n$ git merge --ff-only v3.2.3~\nUpdating 3499d64..7b171c5\nFast-forward\n...\n\n$ git merge --ff-only v3.2.3\nfatal: Not possible to fast-forward, aborting.\n\nAfter talking to Junio, he pointed out that \"merging tag objects gained new\nmeanings in 1.7.9\".\n\nI am not sure if my confusion will be shared by others and if --ff-only\nneeds a clarification.  Perhaps --ff-only should just continue to work as\nit did before, and fast-forward from tag to tag.\n\nCheers,\n-Bart\n"},{"id":"183790","messageId":"7vd39vlbgj.fsf@alter.siamese.dyndns.org","threadId":"29538","inReplyTo":"CADeLxZTsq1M5oEb1u5Oqfxq3dYXL6E_uN9bXaTqaOZiA0fgdJQ@mail.gmail.com","subject":"Re: [1.7.9] usage regression when merging annotated tag objects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-03T23:54:36Z","receivedAt":"2012-02-03T23:54:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Some examples you gave were irrelevant, so I'd give an updated version.\n\nHere are the facts of the day, without judging if the behaviour is good or\nbad.\n\n   1) If you are at Linux v3.2.2 and do not have any development on top, \n\n        $ git merge v3.2.3\n\n      historically would have fast-forwarded. Git v1.7.9 would now create a\n      merge commit, authored by you (who is unlikely to be Linus).\n\n   2) You do not want such a merge, so try to work it around by this:\n\n        $ git merge --ff-only v3.2.3\n\tfatal: Not possible to fast-forward, aborting.\n\n      which is refused because merging a tag object requires a new merge\n      commit.\n\nHere are my assessments.\n\n1. I do not think the first one is a real issue. 99% of the people who are\n   merely following along the upstream will never say \"git merge v3.2.3\".\n   They will instead say \"git pull\" and this _will_ fast-forward.  No\n   merging of tag objects involved.  Also when they want to check out that\n   specific version, they won't be using \"git merge\".  It will be \"git\n   checkout v3.2.3\".  So I do not think this is an issue for the case\n   where it used to result in a fast-forward.\n\n1.5 A variant of the first one is when you have forked and are trying to\n   synchronize with the latest stable. In that case, you _do_ want a merge\n   to happen. It is possible that you may not want to get the \"mergetag\"\n   header in the resulting merge commit, and \"git merge v3.2.3^0\" is a new\n   way to do so.\n\n   Strictly speaking, this _is_ a usage regression caused by the new\n   meaning \"git merge\" gained in v1.7.9.  Recording the tag in the a merge\n   commit, however, is the whole point of \"git merge v3.2.3\" that is given\n   a tag; this behaviour is not going to to change.\n\n2. This is somewhat problematic. \"git merge --ff-only v2.6.29\" to people\n   who merely follow Linus has always been possible, and I would expect it\n   to be the case.\n\n   But again, the reason they said --ff-only in the first place is because\n   they feared that they might have some unexpected commits in their\n   history, and asked \"git merge\" to error out if the command has to\n   create a merge to let them know.  So at that point, they could be\n   trained to run \"git merge --ff-only v3.2.3^0\" instead, *given enough\n   clue*.\n\n   The problem is that we are not giving enough clue.  We just say \"Not\n   possible to fast-forward\" without explaining why.\n\n   We could solve this in one of two ways. We could tell them to merge\n   v3.2.3^0 instead. Or we could just go ahead and do that for them\n   automatically ourselves.  I am inclined to say that we should unwrap\n   the tag given from the command line when --ff-only was given, i.e. we\n   do the latter.\n"},{"id":"183945","messageId":"7vmx8wdd57.fsf@alter.siamese.dyndns.org","threadId":"29538","inReplyTo":"7vd39vlbgj.fsf@alter.siamese.dyndns.org","subject":"merge: do not create a signed tag merge under --ff-only option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-06T00:22:12Z","receivedAt":"2012-02-06T00:22:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Starting at release v1.7.9, if you ask to merge a signed tag, \"git merge\"\nalways creates a merge commit, even when the tag points at a commit that\nhappens to be a descendant of your current commit.\n\nUnfortunately, this interacts rather badly for people who use --ff-only to\nmake sure that their branch is free of local developments. It used to be\npossible to say:\n\n\t$ git checkout -b frotz v1.7.9~30\n        $ git merge --ff-only v1.7.9\n\nand expect that the resulting tip of frotz branch matches v1.7.9^0 (aka\nthe commit tagged as v1.7.9), but this fails with the updated Git with:\n\n\tfatal: Not possible to fast-forward, aborting.\n\nbecause a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by\nfast forwarding.\n\nWe could teach users that now they have to do\n\n\t$ git merge --ff-only v1.7.9^0\n\nbut it is far more pleasant for users if we DWIMmed this ourselves.\n\nWhen an integrator pulls in a topic from a lieutenant via a signed tag,\neven when the work done by the lieutenant happens to fast-forward, the\nintegrator wants to have a merge record, so the integrator will not be\nasking for --ff-only when running \"git pull\" in such a case. Therefore,\nthis change should not regress the support for the use case v1.7.9 wanted\nto add.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n  Junio C Hamano <gitster@pobox.com> writes:\n\n    We could solve this in one of two ways. We could tell them to merge\n    v3.2.3^0 instead. Or we could just go ahead and do that for them\n    automatically ourselves.  I am inclined to say that we should unwrap\n    the tag given from the command line when --ff-only was given, i.e. we\n    do the latter.\n\n  And it turns out that it is just a single-liner patch.\n\n builtin/merge.c  |    3 ++-\n t/t7600-merge.sh |   13 +++++++++++++\n 2 files changed, 15 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 3a45172..b4fbc60 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -1283,7 +1283,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\t\t    sha1_to_hex(commit->object.sha1));\n \t\tsetenv(buf.buf, argv[i], 1);\n \t\tstrbuf_reset(&buf);\n-\t\tif (merge_remote_util(commit) &&\n+\t\tif (!fast_forward_only &&\n+\t\t    merge_remote_util(commit) &&\n \t\t    merge_remote_util(commit)->obj &&\n \t\t    merge_remote_util(commit)->obj->type == OBJ_TAG) {\n \t\t\toption_edit = 1;\ndiff --git a/t/t7600-merge.sh b/t/t7600-merge.sh\nindex 5d8c428..a598dfa 100755\n--- a/t/t7600-merge.sh\n+++ b/t/t7600-merge.sh\n@@ -27,6 +27,7 @@ Testing basic merge operations/option parsing.\n '\n \n . ./test-lib.sh\n+. \"$TEST_DIRECTORY\"/lib-gpg.sh\n \n printf '%s\\n' 1 2 3 4 5 6 7 8 9 >file\n printf '%s\\n' '1 X' 2 3 4 5 6 7 8 9 >file.1\n@@ -670,4 +671,16 @@ test_expect_success 'merge --no-ff --edit' '\n \ttest_cmp actual expected\n '\n \n+test_expect_success GPG 'merge --ff-only tag' '\n+\tgit reset --hard c0 &&\n+\tgit commit --allow-empty -m \"A newer commit\" &&\n+\tgit tag -s -m \"A newer commit\" signed &&\n+\tgit reset --hard c0 &&\n+\n+\tgit merge --ff-only signed &&\n+\tgit rev-parse signed^0 >expect &&\n+\tgit rev-parse HEAD >actual &&\n+\ttest_cmp actual expect\n+'\n+\n test_done\n"}]}