{"thread":{"id":"39877","subject":"Git tag: pre-receive hook issue","startedAt":"2015-07-17T18:58:53Z","lastAt":"2015-07-22T19:46:44Z","messageCount":13,"participants":["Garbageyard","Junio C Hamano","Jacob Keller","Gaurav Chhabra","Keller, Jacob E","Jakub Narębski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"266260","messageId":"1437159533304-7635764.post@n2.nabble.com","threadId":"39877","inReplyTo":null,"subject":"Git tag: pre-receive hook issue","fromName":"Garbageyard","fromEmail":"varuag.chhabra@gmail.com","sentAt":"2015-07-17T18:58:53Z","receivedAt":"2015-07-17T18:58:53Z","isPatch":false,"sender":{"key":"varuag.chhabra@gmail.com","avatar":"https://gravatar.com/avatar/b731428347fdc09c456902cac39c52957f1e296e8edd38f6162400e8402f480e?d=mp&s=160"},"body":"We have a pre-receive hook that checks for JIRA ID whenever someone pushes\ncode to Git server. I'm trying to avoid this check when someone is applying\na tag. Here's the link for the script: http://pastebin.com/VnMQp5ar\n\nThis is the link for output: http://pastebin.com/tBGmYaZF\n\nProblem is that if i run the following command, the output that i get on\ncommand line is 0\n\ngit describe --exact-match ac28ca721e67adc04078786164939989a5112d98 2>&1 |\ngrep -o fatal | wc -w\n\nSo i'm wondering why it's not entering the IF block (as confirmed in the\noutput link)\n\nI agree this is a bad implementation (and i will change it soon) for\nchecking tags and can be easily done by just checking whether $refname\nstarts with refs/tags/ but i'll really appreciate if someone could tell me\nthe mistake i'm committing. I've spent few hours banging my head on this.\n\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"266262","messageId":"xmqqoaja1t0y.fsf@gitster.dls.corp.google.com","threadId":"39877","inReplyTo":"1437159533304-7635764.post@n2.nabble.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-17T19:30:21Z","receivedAt":"2015-07-17T19:30:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Garbageyard writes:\n\n> We have a pre-receive hook that checks for JIRA ID whenever someone pushes\n> code to Git server. I'm trying to avoid this check when someone is applying\n> a tag. Here's the link for the script: http://pastebin.com/VnMQp5ar\n>\n> This is the link for output: http://pastebin.com/tBGmYaZF\n>\n> Problem is that if i run the following command, the output that i get on\n> command line is 0\n>\n> git describe --exact-match ac28ca721e67adc04078786164939989a5112d98 2>&1 |\n> grep -o fatal | wc -w\n\nI am not sure what you are trying to do in the first place.\n\n : gitster x; git init garbage\n Initialized empty Git repository in /var/tmp/x/garbage/.git/\n : gitster x; cd garbage\n : gitster garbage/master; git commit --allow-empty -m initial\n [master (root-commit) b18cac2] initial\n : gitster garbage/master; git tag v0.0 ;# lightweight\n : gitster garbage/master; git commit --allow-empty -m second\n [master d1de78e] second\n : gitster garbage/master; git tag -a 'v0.1' v0.1\n fatal: Failed to resolve 'v0.1' as a valid ref.\n : gitster garbage/master; git tag -a -m 'v0.1' v0.1\n : gitster garbage/master; git commit --allow-empty -m third\n [master d1f1360] third\n : gitster garbage/master; git describe --exact-match HEAD ;# third\n fatal: no tag exactly matches 'd1f1360b46dfde8c6f341e48ce45d761ed37e357'\n : gitster garbage/master; git describe --exact-match HEAD^ ;# second\n v0.1\n : gitster garbage/master; git describe --exact-match HEAD^^ ;# first\n fatal: no tag exactly matches 'b18cac237055d9518f9f92bb4c0a4dac825dce17'\n : gitster garbage/master; exit\n\nI am feeding three _commits_, not tags. But one of them (i.e. the\none that happens to have an annotated tag) yields the \"exact match\"\ntagname, as designed and expected.\n\nBut is it really what you want to do to skip such a commit? Why?\n\nI also see a questionable thing in the earlier part of your script:\n\n while read old_sha1 new_sha1 refname ; do\n echo \"stdin: [$old_sha1] [$new_sha1] [$refname]\"\n if [ \"$old_sha1\" == \"0000000000000000000000000000000000000000\" ] ; then\n commits=$new_sha1\n else\n commits=`git rev-list $old_sha1..$new_sha1`\n fi\n\n for commit in $commits\n do\n\t\t...\n\nWhen somebody pushes to an existing branch, you list all the new\ncommits that came in (i.e. 'git rev-list' is bounded by $old_sha1 at\nthe bottom). But when somebody pushes to a new branch, you only\ninclude the tip to the list.\n\nAnd you check everything on that list. Why? If I push three-commit\nseries to a new branch, wouldn't you want to validate all three of\nthem, just like you validate my push of a three-commit enhancement\nto an existing branch?\n\n\twhile read old new name\n do\n\t\tcase \"$name\" in refs/heads/tags/*) continue ;; esac\n\t\tif test \"$old\" = 0000000000000000000000000000000000000000\n\t\tthen\n\t\t\tgit rev-list $old\n\t\telse\n \tgit rev-list $old..$new\n\t\tfi\n\tdone |\n\twhile read commit\n do\n \tDo a check on $commit\n\tdone\n\nor something instead?\n"},{"id":"266319","messageId":"CA+P7+xoXgSHPVhMTm_GZbq+6Pps5yttK2rBZpMycTUFGfqOCvw@mail.gmail.com","threadId":"39877","inReplyTo":"1437159533304-7635764.post@n2.nabble.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-18T04:00:46Z","receivedAt":"2015-07-18T04:00:46Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Fri, Jul 17, 2015 at 11:58 AM, Garbageyard wrote:\n> We have a pre-receive hook that checks for JIRA ID whenever someone pushes\n> code to Git server. I'm trying to avoid this check when someone is applying\n> a tag. Here's the link for the script: http://pastebin.com/VnMQp5ar\n>\n> This is the link for output: http://pastebin.com/tBGmYaZF\n>\n> Problem is that if i run the following command, the output that i get on\n> command line is 0\n>\n> git describe --exact-match ac28ca721e67adc04078786164939989a5112d98 2>&1 |\n> grep -o fatal | wc -w\n>\n> So i'm wondering why it's not entering the IF block (as confirmed in the\n> output link)\n>\n\nProbably due to environment variables set by the git hook. But.. this\nis definitely not at *ALL* what you want to do. Junio has a good\nexplanation below. This doesn't make even any sense at all to me...\n\n> I agree this is a bad implementation (and i will change it soon) for\n> checking tags and can be easily done by just checking whether $refname\n> starts with refs/tags/ but i'll really appreciate if someone could tell me\n> the mistake i'm committing. I've spent few hours banging my head on this.\n>\n>\n>\n\nOk, so the issue I believe is this:\n\nyou're running git describe on the local side. But the pre-receive\nhook hasn't actually accepted the ref yet so git-describe on the\nserver will fail.\n\nThis is why you should just check refs/tags/* as regular pre-receive\nhook examples do.\n\nRegards,\nJake\n\n> --\n> View this message in context: http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764.html\n> Sent from the git mailing list archive at Nabble.com.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"266341","messageId":"CAGDgvc2F7UMWTVrRFt5eK2xmbfz-kyWh6Vp-eQNEj7tixzRPYQ@mail.gmail.com","threadId":"39877","inReplyTo":"CA+P7+xoXgSHPVhMTm_GZbq+6Pps5yttK2rBZpMycTUFGfqOCvw@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Gaurav Chhabra","fromEmail":"varuag.chhabra@gmail.com","sentAt":"2015-07-18T20:08:28Z","receivedAt":"2015-07-18T20:08:28Z","isPatch":false,"sender":{"key":"varuag.chhabra@gmail.com","avatar":"https://gravatar.com/avatar/b731428347fdc09c456902cac39c52957f1e296e8edd38f6162400e8402f480e?d=mp&s=160"},"body":"Thanks for the comments Junio/Jacob! Actually, the script was written\nby someone before i came and the tag check was also done by my\ncolleague recently. I was also trying to implement the tag check\n(using refs/tags which i did saw in few links online) but since my\ncolleague implemented this 'git describe' thing first and it looked\nlike it was working for few cases that we tried, so we left it as is.\nFrankly, since everything 'seemed' to be working well so far, i never\nreally quite looked into it. Now i guess, it's time to correct it.\n\n\n@Junio: From the example you gave, i could conclude the following:\n\n1) : gitster garbage/master; git commit --allow-empty -m third\n [master d1f1360] third\n : gitster garbage/master; git describe --exact-match HEAD ;# third\n fatal: no tag exactly matches 'd1f1360b46dfde8c6f341e48ce45d761ed37e357'\n\n> Since after # third commit, no tag was applied to HEAD, so --exact-match resulted in fatal error\n\n2) : gitster garbage/master; git commit --allow-empty -m second\n[master d1de78e] second\n: gitster garbage/master; git tag -a -m 'v0.1' v0.1\n: gitster garbage/master; git describe --exact-match HEAD^ ;# second\n v0.1\n> Since annotated tag was applied after # second commit, so --exact-match did referenced the commit as expected.\n\n3) : gitster garbage/master; git commit --allow-empty -m initial\n [master (root-commit) b18cac2] initial\n : gitster garbage/master; git tag v0.0 ;# lightweight\n : gitster garbage/master; git describe --exact-match HEAD^^ ;# first\n fatal: no tag exactly matches 'b18cac237055d9518f9f92bb4c0a4dac825dce17'\n\n> In this case, it's a lightweight tag and i read today that by default, git describe only shows annotated tags (without --all or --tags). I think it's because of the missing option (--all or --tags) that it resulted in fatal error in this case.\n\nPlease correct me if i misunderstood any/all of the above cases.\n\nMy queries:\nA) When you mentioned: \"I am feeding three _commits_, not tags.\", i\ndidn't really get what you're trying to highlight. Is it that the code\ni shared 'incorrectly' uses 'git describe' command because it's\npassing the commit ($new_sha1) associated with pushing of the tag\n_instead_ of passing the commit id that the tag actually points to?\n\nB) Coming to the earlier part of the code that you questioned. Thanks\nfor that. As i mentioned above, some guy had written it long time back\n(few years). And again, since this never caused any issue, we never\nlooked into it. I did read a little about rev-list today but i think\ni'll have to try it out on my machine to understand it well. Will read\nmore and then implement the check but yes, i do get an idea what\nyou've tried to question. Basically, for new branch or new\ndevelopment, we are not really doing complete checks. Correct?\n\nYou've also mentioned that \"And you check everything on that list. Why?\"\n> Was this comment for the portion where the code is validating commits (git rev-list $old_sha1..$new_sha1) for existing branch? If yes, then i didn't really get your concern. Can you kindly elaborate a bit?\n\nAnd thanks for sharing the modified version! :)\n\n\n@Jacob: You're right. If i understood correctly what Junio explained,\nthen what the code is doing really shouldn't make any sense at all. :)\n\nBy the way, you mentioned, \"Ok, so the issue I believe is this: you're\nrunning git describe on the local side. But the pre-receive hook\nhasn't actually accepted the ref yet so git-describe on the server\nwill fail.\"\n> When i push a tag, then as per the output i shared, the commit id associated with my tag push is ac28ca721e67a. So if i do a \"git describe --exact-match ac28ca721e67a\", then\n\n1) First of all, it shouldn't make any sense because as \"git describe\"\nshould accept _actual_ commit id and not the commit id generated for\ntag push, isn't it?\n\n2) If i got the above right, then shouldn't Git throw an error even on\nmy local machine when i'm running \"git describe --exact-match\nac28ca721e67a\"?\n\n\n@Junio/Jacob: I think i've asked quite a number of questions above but\ni will really appreciate if you could spare some time to clear these\ndoubts. I'm definitely going to change this junk code but i would like\nto be sure that i've understood your explanations well.\n\n\nThanks!\n\nOn Sat, Jul 18, 2015 at 9:30 AM, Jacob Keller wrote:\n> On Fri, Jul 17, 2015 at 11:58 AM, Garbageyard wrote:\n>> We have a pre-receive hook that checks for JIRA ID whenever someone pushes\n>> code to Git server. I'm trying to avoid this check when someone is applying\n>> a tag. Here's the link for the script: http://pastebin.com/VnMQp5ar\n>>\n>> This is the link for output: http://pastebin.com/tBGmYaZF\n>>\n>> Problem is that if i run the following command, the output that i get on\n>> command line is 0\n>>\n>> git describe --exact-match ac28ca721e67adc04078786164939989a5112d98 2>&1 |\n>> grep -o fatal | wc -w\n>>\n>> So i'm wondering why it's not entering the IF block (as confirmed in the\n>> output link)\n>>\n>\n> Probably due to environment variables set by the git hook. But.. this\n> is definitely not at *ALL* what you want to do. Junio has a good\n> explanation below. This doesn't make even any sense at all to me...\n>\n>> I agree this is a bad implementation (and i will change it soon) for\n>> checking tags and can be easily done by just checking whether $refname\n>> starts with refs/tags/ but i'll really appreciate if someone could tell me\n>> the mistake i'm committing. I've spent few hours banging my head on this.\n>>\n>>\n>>\n>\n> Ok, so the issue I believe is this:\n>\n> you're running git describe on the local side. But the pre-receive\n> hook hasn't actually accepted the ref yet so git-describe on the\n> server will fail.\n>\n> This is why you should just check refs/tags/* as regular pre-receive\n> hook examples do.\n>\n> Regards,\n> Jake\n>\n>> --\n>> View this message in context: http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764.html\n>> Sent from the git mailing list archive at Nabble.com.\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"266343","messageId":"xmqqtwt1yxil.fsf@gitster.dls.corp.google.com","threadId":"39877","inReplyTo":"CAGDgvc2F7UMWTVrRFt5eK2xmbfz-kyWh6Vp-eQNEj7tixzRPYQ@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-18T21:19:14Z","receivedAt":"2015-07-18T21:19:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gaurav Chhabra writes:\n\n> @Junio: From the example you gave, i could conclude the following:\n>\n> 1) : gitster garbage/master; git commit --allow-empty -m third\n> [master d1f1360] third\n> : gitster garbage/master; git describe --exact-match HEAD ;# third\n> fatal: no tag exactly matches 'd1f1360b46dfde8c6f341e48ce45d761ed37e357'\n>\n>> Since after # third commit, no tag was applied to HEAD, so\n>> --exact-match resulted in fatal error\n>\n> 2) : gitster garbage/master; git commit --allow-empty -m second\n> [master d1de78e] second\n> : gitster garbage/master; git tag -a -m 'v0.1' v0.1\n> : gitster garbage/master; git describe --exact-match HEAD^ ;# second\n> v0.1\n>> Since annotated tag was applied after # second commit, so\n>> --exact-match did referenced the commit as expected.\n>\n> 3) : gitster garbage/master; git commit --allow-empty -m initial\n> [master (root-commit) b18cac2] initial\n> : gitster garbage/master; git tag v0.0 ;# lightweight\n> : gitster garbage/master; git describe --exact-match HEAD^^ ;# first\n> fatal: no tag exactly matches 'b18cac237055d9518f9f92bb4c0a4dac825dce17'\n>\n>> In this case, it's a lightweight tag and i read today that by\n>> default, git describe only shows annotated tags (without --all or\n>> --tags). I think it's because of the missing option (--all or\n>> --tags) that it resulted in fatal error in this case.\n>\n> Please correct me if i misunderstood any/all of the above cases.\n\nAll correct. The part that I find questionable is that by checking\nwith \"is this commit a tagged one?\" and doing different things.\nWhat makes the initial and the third special to deserve checking\n(because they are not annotated with a tag) while skipping the\nvalidation for the second (merely because it has an annotated tag\nadded to it)?\n\n> My queries:\n> A) When you mentioned: \"I am feeding three _commits_, not tags.\", i\n> didn't really get what you're trying to highlight.\n\nI was skipping one round-trip, expecting for you to say \"the part\nthat sets 'commit=$new' for a newly created branch was a mistake,\nand it should do 'commit=$(git rev-list $new)'\". And even when $new\nis a tag, what comes out of `git rev-list $new` is a sequence of\ncommit object names, never the tag object.\n\n> You've also mentioned that \"And you check everything on that list. Why?\"\n>> Was this comment for the portion where the code is validating\n>> commits (git rev-list $old_sha1..$new_sha1) for existing branch? If\n>> yes, then i didn't really get your concern. Can you kindly elaborate\n>> a bit?\n\nI do not question the validity of checking everything between $old..$new;\nmy question was more about \"even though you correctly check everything,\nwhy do you check _only_ the tip by doing 'commit=$new' (instead of\ndoing 'commit=`git rev-list $new`') when somebody pushes to a new branch?\".\n\n>>> git describe --exact-match ac28ca721e67adc04078786164939989a5112d98 2>&1 |\n>>> grep -o fatal | wc -w\n>>>\n>>> So i'm wondering why it's not entering the IF block (as confirmed in the\n>>> output link)\n\nWhen you push a branch 'master' and a tag 'v1.0', these things\nhappen in order:\n\n (1) all objects that are necessary to ensure that the receiving\n repository has everything reachable from 'master' and 'v1.0'\n are sent to it and stored. If the receiving end fails to store\n this correctly, everything below is skipped and the operation\n fails.\n\n (2) pre-receive is run. Notice that at this point, no refs have\n been updated yet, so \"describe\" will not know v1.0 tag (if it\n is a new one) exists. But this step can assume that all new\n objects are already accessible using their object name, so\n\n\tcase \"$old\" in\n 0000000000000000000000000000000000000000) range=$new ;;\n *) bottom=$old..$new ;;\n\tesac &&\n \tgit rev-list $range |\n while read commit\n do\n \tcheck $commit object, e.g.\n git cat-file commit $commit | grep FooBarId\n\tdone\n\n is expected to work.\n\n (3) for each ref being updated (in this case, refs/heads/master and\n refs/tags/v1.0), the following happens:\n\n (3-1) built-in sanity checks may reject the push to the ref,\n e.g. refusing to update a checked out branch, refusing to\n accept a non-fast-forward push that is not forced, etc.\n\n (3-2) update-hook is run, which may reject the push to this\n ref.\n\n (3-3) the ref is updated (unless the push is atomic).\n\n (4) if the push is atomic, the refs are updated.\n\n (5) post-receive hook is run. This is for logging and cannot\n affect the outcome of the push.\n\n (6) for each ref that was updated (in this case, refs/heads/master\n and refs/tags/v1.0), post-update hook is run. This is for\n logging and cannot affect the outcome of the push.\n\n\nAs your requirement seems to be to validate any and all new commits,\nI think it is totally unnecessary to check if any of them happens to\nhave a tag pointing at it in the first place.\n"},{"id":"266349","messageId":"CA+P7+xrbWt=n6hj4bTcdLRMPXa0K51gErNBD-omQy+g-So6TYw@mail.gmail.com","threadId":"39877","inReplyTo":"CAGDgvc2F7UMWTVrRFt5eK2xmbfz-kyWh6Vp-eQNEj7tixzRPYQ@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-18T22:22:18Z","receivedAt":"2015-07-18T22:22:18Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sat, Jul 18, 2015 at 1:08 PM, Gaurav Chhabra\n wrote:\n> Thanks for the comments Junio/Jacob! Actually, the script was written\n> by someone before i came and the tag check was also done by my\n> colleague recently. I was also trying to implement the tag check\n> (using refs/tags which i did saw in few links online) but since my\n> colleague implemented this 'git describe' thing first and it looked\n> like it was working for few cases that we tried, so we left it as is.\n> Frankly, since everything 'seemed' to be working well so far, i never\n> really quite looked into it. Now i guess, it's time to correct it.\n>\n>\n> @Junio: From the example you gave, i could conclude the following:\n>\n> 1) : gitster garbage/master; git commit --allow-empty -m third\n> [master d1f1360] third\n> : gitster garbage/master; git describe --exact-match HEAD ;# third\n> fatal: no tag exactly matches 'd1f1360b46dfde8c6f341e48ce45d761ed37e357'\n>\n>> Since after # third commit, no tag was applied to HEAD, so --exact-match resulted in fatal error\n>\n> 2) : gitster garbage/master; git commit --allow-empty -m second\n> [master d1de78e] second\n> : gitster garbage/master; git tag -a -m 'v0.1' v0.1\n> : gitster garbage/master; git describe --exact-match HEAD^ ;# second\n> v0.1\n>> Since annotated tag was applied after # second commit, so --exact-match did referenced the commit as expected.\n>\n> 3) : gitster garbage/master; git commit --allow-empty -m initial\n> [master (root-commit) b18cac2] initial\n> : gitster garbage/master; git tag v0.0 ;# lightweight\n> : gitster garbage/master; git describe --exact-match HEAD^^ ;# first\n> fatal: no tag exactly matches 'b18cac237055d9518f9f92bb4c0a4dac825dce17'\n>\n>> In this case, it's a lightweight tag and i read today that by default, git describe only shows annotated tags (without --all or --tags). I think it's because of the missing option (--all or --tags) that it resulted in fatal error in this case.\n>\n> Please correct me if i misunderstood any/all of the above cases.\n>\n> My queries:\n> A) When you mentioned: \"I am feeding three _commits_, not tags.\", i\n> didn't really get what you're trying to highlight. Is it that the code\n> i shared 'incorrectly' uses 'git describe' command because it's\n> passing the commit ($new_sha1) associated with pushing of the tag\n> _instead_ of passing the commit id that the tag actually points to?\n>\n> B) Coming to the earlier part of the code that you questioned. Thanks\n> for that. As i mentioned above, some guy had written it long time back\n> (few years). And again, since this never caused any issue, we never\n> looked into it. I did read a little about rev-list today but i think\n> i'll have to try it out on my machine to understand it well. Will read\n> more and then implement the check but yes, i do get an idea what\n> you've tried to question. Basically, for new branch or new\n> development, we are not really doing complete checks. Correct?\n>\n> You've also mentioned that \"And you check everything on that list. Why?\"\n>> Was this comment for the portion where the code is validating commits (git rev-list $old_sha1..$new_sha1) for existing branch? If yes, then i didn't really get your concern. Can you kindly elaborate a bit?\n>\n> And thanks for sharing the modified version! :)\n>\n>\n> @Jacob: You're right. If i understood correctly what Junio explained,\n> then what the code is doing really shouldn't make any sense at all. :)\n>\n> By the way, you mentioned, \"Ok, so the issue I believe is this: you're\n> running git describe on the local side. But the pre-receive hook\n> hasn't actually accepted the ref yet so git-describe on the server\n> will fail.\"\n>> When i push a tag, then as per the output i shared, the commit id associated with my tag push is ac28ca721e67a. So if i do a \"git describe --exact-match ac28ca721e67a\", then\n>\n> 1) First of all, it shouldn't make any sense because as \"git describe\"\n> should accept _actual_ commit id and not the commit id generated for\n> tag push, isn't it?\n\n\ngit describe will attempt to describe the commit ID you pass it. But\nthe tag object for a \"new\" tag push will not get \"described\" because\nthe pre-receive hook runs before you push it.\n\nIt would help a lot if we understood exactly what you are trying to accomplish.\n\nIf you run git describe locally, it will find the annotated tag you\nmade. If you run this remotely during the pre-receive of the tag that\nyou now now pushing it will not. ie:\n\n$git tag -a some-new-tag ac28ca721e67a\n$git describe --exact-match ac28ca721e67a\n\ngit describe --exact-match ac28ca721e67a\n\n\nSee the difference here? Maybe this isn't what you are trying to do at\nall? What exactly behavior do you want to not allow?\n\nRegards,\nJake\n\n>\n> 2) If i got the above right, then shouldn't Git throw an error even on\n> my local machine when i'm running \"git describe --exact-match\n> ac28ca721e67a\"?\n>\n\nNot with my example above. But maybe I'm incorrect entirely in what\nyou are actually doing?\n\n>\n> @Junio/Jacob: I think i've asked quite a number of questions above but\n> i will really appreciate if you could spare some time to clear these\n> doubts. I'm definitely going to change this junk code but i would like\n> to be sure that i've understood your explanations well.\n>\n>\n"},{"id":"266369","messageId":"CAGDgvc3O=q-k3ViiEds4iPMtDQTOSFMSJ4bUKRFyWzqwv7=J_Q@mail.gmail.com","threadId":"39877","inReplyTo":"CA+P7+xrbWt=n6hj4bTcdLRMPXa0K51gErNBD-omQy+g-So6TYw@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Gaurav Chhabra","fromEmail":"varuag.chhabra@gmail.com","sentAt":"2015-07-19T07:55:30Z","receivedAt":"2015-07-19T07:55:30Z","isPatch":false,"sender":{"key":"varuag.chhabra@gmail.com","avatar":"https://gravatar.com/avatar/b731428347fdc09c456902cac39c52957f1e296e8edd38f6162400e8402f480e?d=mp&s=160"},"body":"@Junio: So from your detailed explanation (and Jake's comment), i\nunderstand that since my ref wasn't updated on remote so querying the\nsame using \"git describe\" resulted in failure, and hence, code was not\nentering the IF block. Correct?\n\nAlso, while i was reading your replies, i was just thinking that the\nfollowing question that i asked Jake doesn't really make sense because\na commit object _is_ being passed (on local machine) to \"git\ndescribe\", which is what it expects so it should work for sure:\n\n\"If i got the above right, then shouldn't Git throw an error even on\nmy local machine when i'm running \"git describe --exact-match\nac28ca721e67a\"?\"\n\n@Junio: You wrote: \"The part that I find questionable is that by\nchecking with \"is this commit a tagged one?\" and doing different\nthings. What makes the initial and the third special to deserve\nchecking (because they are not annotated with a tag) while skipping\nthe validation for the second (merely because it has an annotated tag\nadded to it)?\"\n> Isn't the code that i shared doing just the opposite of what you've written? It's checking for annotated tags only and skipping the lightweight ones (although it shouldn't be doing all such things in the first place). Was it a typo on your part?\n\n\n@Jake: For the question you asked: \"It would help a lot if we\nunderstood exactly what you are trying to accomplish.\"\n> I'm not sure how my colleague zeroed in on this \"git describe\" command but i at least know what we observed (and 'seemed' to work). We saw that if we use git-describe and pass a commit object, it throws fatal error message. On the other hand, if we pass a tag object, it doesn't throw any fatal error. That's the reason he added that tag check portion.\n\n\n@Junio/Jake: After going through all the responses that i've received\nso far on this forum, i'm thinking how this nonsense code worked for\nfew cases in the past? When this check was put in place, devs were\ngetting error while pushing annotated tags. Since we use Gitolite, we\nadded the following to gitolite.conf and the tag push worked for them:\n\nRW+ refs/tags=developer_name\n\nI'm wondering why.\n\n\nOn Sun, Jul 19, 2015 at 3:52 AM, Jacob Keller [via git]\n wrote:\n> On Sat, Jul 18, 2015 at 1:08 PM, Gaurav Chhabra\n> <[hidden email]> wrote:\n>\n>> Thanks for the comments Junio/Jacob! Actually, the script was written\n>> by someone before i came and the tag check was also done by my\n>> colleague recently. I was also trying to implement the tag check\n>> (using refs/tags which i did saw in few links online) but since my\n>> colleague implemented this 'git describe' thing first and it looked\n>> like it was working for few cases that we tried, so we left it as is.\n>> Frankly, since everything 'seemed' to be working well so far, i never\n>> really quite looked into it. Now i guess, it's time to correct it.\n>>\n>>\n>> @Junio: From the example you gave, i could conclude the following:\n>>\n>> 1) : gitster garbage/master; git commit --allow-empty -m third\n>> [master d1f1360] third\n>> : gitster garbage/master; git describe --exact-match HEAD ;# third\n>> fatal: no tag exactly matches 'd1f1360b46dfde8c6f341e48ce45d761ed37e357'\n>>\n>>> Since after # third commit, no tag was applied to HEAD, so --exact-match\n>>> resulted in fatal error\n>>\n>> 2) : gitster garbage/master; git commit --allow-empty -m second\n>> [master d1de78e] second\n>> : gitster garbage/master; git tag -a -m 'v0.1' v0.1\n>> : gitster garbage/master; git describe --exact-match HEAD^ ;# second\n>> v0.1\n>>> Since annotated tag was applied after # second commit, so --exact-match\n>>> did referenced the commit as expected.\n>>\n>> 3) : gitster garbage/master; git commit --allow-empty -m initial\n>> [master (root-commit) b18cac2] initial\n>> : gitster garbage/master; git tag v0.0 ;# lightweight\n>> : gitster garbage/master; git describe --exact-match HEAD^^ ;# first\n>> fatal: no tag exactly matches 'b18cac237055d9518f9f92bb4c0a4dac825dce17'\n>>\n>>> In this case, it's a lightweight tag and i read today that by default,\n>>> git describe only shows annotated tags (without --all or --tags). I think\n>>> it's because of the missing option (--all or --tags) that it resulted in\n>>> fatal error in this case.\n>>\n>> Please correct me if i misunderstood any/all of the above cases.\n>>\n>> My queries:\n>> A) When you mentioned: \"I am feeding three _commits_, not tags.\", i\n>> didn't really get what you're trying to highlight. Is it that the code\n>> i shared 'incorrectly' uses 'git describe' command because it's\n>> passing the commit ($new_sha1) associated with pushing of the tag\n>> _instead_ of passing the commit id that the tag actually points to?\n>>\n>> B) Coming to the earlier part of the code that you questioned. Thanks\n>> for that. As i mentioned above, some guy had written it long time back\n>> (few years). And again, since this never caused any issue, we never\n>> looked into it. I did read a little about rev-list today but i think\n>> i'll have to try it out on my machine to understand it well. Will read\n>> more and then implement the check but yes, i do get an idea what\n>> you've tried to question. Basically, for new branch or new\n>> development, we are not really doing complete checks. Correct?\n>>\n>> You've also mentioned that \"And you check everything on that list. Why?\"\n>>> Was this comment for the portion where the code is validating commits\n>>> (git rev-list $old_sha1..$new_sha1) for existing branch? If yes, then i\n>>> didn't really get your concern. Can you kindly elaborate a bit?\n>>\n>> And thanks for sharing the modified version! :)\n>>\n>>\n>> @Jacob: You're right. If i understood correctly what Junio explained,\n>> then what the code is doing really shouldn't make any sense at all. :)\n>>\n>> By the way, you mentioned, \"Ok, so the issue I believe is this: you're\n>> running git describe on the local side. But the pre-receive hook\n>> hasn't actually accepted the ref yet so git-describe on the server\n>> will fail.\"\n>>> When i push a tag, then as per the output i shared, the commit id\n>>> associated with my tag push is ac28ca721e67a. So if i do a \"git describe\n>>> --exact-match ac28ca721e67a\", then\n>>\n>> 1) First of all, it shouldn't make any sense because as \"git describe\"\n>> should accept _actual_ commit id and not the commit id generated for\n>> tag push, isn't it?\n>\n>\n> git describe will attempt to describe the commit ID you pass it. But\n> the tag object for a \"new\" tag push will not get \"described\" because\n> the pre-receive hook runs before you push it.\n>\n> It would help a lot if we understood exactly what you are trying to\n> accomplish.\n>\n> If you run git describe locally, it will find the annotated tag you\n> made. If you run this remotely during the pre-receive of the tag that\n> you now now pushing it will not. ie:\n>\n> $git tag -a some-new-tag ac28ca721e67a\n> $git describe --exact-match ac28ca721e67a\n> $git push origin some-new-tag\n> \n> git describe --exact-match ac28ca721e67a\n> \n>\n> See the difference here? Maybe this isn't what you are trying to do at\n> all? What exactly behavior do you want to not allow?\n>\n> Regards,\n> Jake\n>\n>>\n>> 2) If i got the above right, then shouldn't Git throw an error even on\n>> my local machine when i'm running \"git describe --exact-match\n>> ac28ca721e67a\"?\n>>\n>\n> Not with my example above. But maybe I'm incorrect entirely in what\n> you are actually doing?\n>\n>>\n>> @Junio/Jacob: I think i've asked quite a number of questions above but\n>> i will really appreciate if you could spare some time to clear these\n>> doubts. I'm definitely going to change this junk code but i would like\n>> to be sure that i've understood your explanations well.\n>>\n>>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to [hidden email]\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n>\n> ________________________________\n> If you reply to this email, your message will be added to the discussion\n> below:\n> http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764p7635854.html\n> To unsubscribe from Git tag: pre-receive hook issue, click here.\n> NAML\n"},{"id":"266370","messageId":"CA+P7+xpevvV=5QdfBdzcD=8=2ff+m-kzxX-w1wLME8oRyn8QBA@mail.gmail.com","threadId":"39877","inReplyTo":"CAGDgvc3O=q-k3ViiEds4iPMtDQTOSFMSJ4bUKRFyWzqwv7=J_Q@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-19T08:38:43Z","receivedAt":"2015-07-19T08:38:43Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sun, Jul 19, 2015 at 12:55 AM, Gaurav Chhabra\n wrote:\n> @Junio: So from your detailed explanation (and Jake's comment), i\n> understand that since my ref wasn't updated on remote so querying the\n> same using \"git describe\" resulted in failure, and hence, code was not\n> entering the IF block. Correct?\n>\n\nI assume so.\n\n> Also, while i was reading your replies, i was just thinking that the\n> following question that i asked Jake doesn't really make sense because\n> a commit object _is_ being passed (on local machine) to \"git\n> describe\", which is what it expects so it should work for sure:\n>\n\nIt works yes. Git describe finds the nearest tag. --exact-match fails\nunless it can find a tag at the commit specified.\n\n> \"If i got the above right, then shouldn't Git throw an error even on\n> my local machine when i'm running \"git describe --exact-match\n> ac28ca721e67a\"?\"\n>\n\nonly if ac28ca721e67a does not have an annotated tag associated to it\n\n\n\n> @Junio: You wrote: \"The part that I find questionable is that by\n> checking with \"is this commit a tagged one?\" and doing different\n> things. What makes the initial and the third special to deserve\n> checking (because they are not annotated with a tag) while skipping\n> the validation for the second (merely because it has an annotated tag\n> added to it)?\"\n>> Isn't the code that i shared doing just the opposite of what you've written? It's checking for annotated tags only and skipping the lightweight ones (although it shouldn't be doing all such things in the first place). Was it a typo on your part?\n>\n>\n\nI'm not sure what the code you have is trying to do. See below.\n\n> @Jake: For the question you asked: \"It would help a lot if we\n> understood exactly what you are trying to accomplish.\"\n>> I'm not sure how my colleague zeroed in on this \"git describe\" command but i at least know what we observed (and 'seemed' to work). We saw that if we use git-describe and pass a commit object, it throws fatal error message. On the other hand, if we pass a tag object, it doesn't throw any fatal error. That's the reason he added that tag check portion.\n>\n\nHmmm....\n\n>\n> @Junio/Jake: After going through all the responses that i've received\n> so far on this forum, i'm thinking how this nonsense code worked for\n> few cases in the past? When this check was put in place, devs were\n> getting error while pushing annotated tags. Since we use Gitolite, we\n> added the following to gitolite.conf and the tag push worked for them:\n>\n> RW+ refs/tags=developer_name\n>\n\nSounds like you needed to add RW permissions to the refs/tags namespace.\n\n> I'm wondering why.\n>\n\nOk, so normally, pre-receive hook is used to implement policy. Ie:\nprevent acceptance of pushes that have \"bad\" content as defined by the\nrepository owner. For example, preventing push of tags that don't\nmatch some format, or preventing pushes which contain bad stuff.\n\nI could provide some examples or suggestions if you would describe\nwhat sort of policy you're trying to enforce..\n\ngit describe will tell you if the commit you're passing it is\nassociated with an annotated tag. I do not understand who this\ninformation can help you implement any policy, so understanding what\nthe policy you want is would be the most helpful.\n\nI can't really help more or understand exactly what you were doing\nwithout understanding what policy you were/are trying to implement.\n\nThe thing your code is doing today is something like:\n\nfor each reference update, locate every commit\n\nfor each commit in this reference update, check to see if it already\nhas an associated tag connected to it.\n\nIf it doesn't have a tag, then \"do some more checks\" which are not\ndescribed here.\n\nThis doesn't make sense to me at all. I think what you *meant* was this:\n\nfor each reference update, if the reference being updated is a tag, skip it\n\notherwise, for each commit in the reference update do some checks on it.\n\nThat is *completely* different from the code you've written today.\n\nRegards,\nJake\n"},{"id":"266372","messageId":"CAGDgvc1CwmQV75mo22v5LQH4q-kNMFtVq3Y9eSt9LL44JHr5Og@mail.gmail.com","threadId":"39877","inReplyTo":"CA+P7+xpevvV=5QdfBdzcD=8=2ff+m-kzxX-w1wLME8oRyn8QBA@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Gaurav Chhabra","fromEmail":"varuag.chhabra@gmail.com","sentAt":"2015-07-19T10:13:54Z","receivedAt":"2015-07-19T10:13:54Z","isPatch":false,"sender":{"key":"varuag.chhabra@gmail.com","avatar":"https://gravatar.com/avatar/b731428347fdc09c456902cac39c52957f1e296e8edd38f6162400e8402f480e?d=mp&s=160"},"body":"The only thing we wanted to check was whether a ref is a tag. :) Rest\nother things are working fine (except for the \"commits=$new_sha1\"\nthing which Junio already pointed out and corrected). I will correct\nthe pre-receive hook.\n\nThe only mystery that remains is about the current nonsensical code\nworking fine in the past for few annotated tag pushes. It shouldn't\nhave worked just by providing:\n\nRW+ refs/tags=developer_name\n\nRef: http://gitolite.com/gitolite/g2/aac.html (Section: \"deny\" rules\nfor refs in a repo)\n\n\nOn Sun, Jul 19, 2015 at 2:09 PM, Jacob Keller [via git]\n wrote:\n> On Sun, Jul 19, 2015 at 12:55 AM, Gaurav Chhabra\n> <[hidden email]> wrote:\n>> @Junio: So from your detailed explanation (and Jake's comment), i\n>> understand that since my ref wasn't updated on remote so querying the\n>> same using \"git describe\" resulted in failure, and hence, code was not\n>> entering the IF block. Correct?\n>>\n>\n> I assume so.\n>\n>> Also, while i was reading your replies, i was just thinking that the\n>> following question that i asked Jake doesn't really make sense because\n>> a commit object _is_ being passed (on local machine) to \"git\n>> describe\", which is what it expects so it should work for sure:\n>>\n>\n> It works yes. Git describe finds the nearest tag. --exact-match fails\n> unless it can find a tag at the commit specified.\n>\n>> \"If i got the above right, then shouldn't Git throw an error even on\n>> my local machine when i'm running \"git describe --exact-match\n>> ac28ca721e67a\"?\"\n>>\n>\n> only if ac28ca721e67a does not have an annotated tag associated to it\n>\n>\n>\n>> @Junio: You wrote: \"The part that I find questionable is that by\n>> checking with \"is this commit a tagged one?\" and doing different\n>> things. What makes the initial and the third special to deserve\n>> checking (because they are not annotated with a tag) while skipping\n>> the validation for the second (merely because it has an annotated tag\n>> added to it)?\"\n>>> Isn't the code that i shared doing just the opposite of what you've\n>>> written? It's checking for annotated tags only and skipping the lightweight\n>>> ones (although it shouldn't be doing all such things in the first place).\n>>> Was it a typo on your part?\n>>\n>>\n>\n> I'm not sure what the code you have is trying to do. See below.\n>\n>> @Jake: For the question you asked: \"It would help a lot if we\n>> understood exactly what you are trying to accomplish.\"\n>>> I'm not sure how my colleague zeroed in on this \"git describe\" command\n>>> but i at least know what we observed (and 'seemed' to work). We saw that if\n>>> we use git-describe and pass a commit object, it throws fatal error message.\n>>> On the other hand, if we pass a tag object, it doesn't throw any fatal\n>>> error. That's the reason he added that tag check portion.\n>>\n>\n> Hmmm....\n>\n>>\n>> @Junio/Jake: After going through all the responses that i've received\n>> so far on this forum, i'm thinking how this nonsense code worked for\n>> few cases in the past? When this check was put in place, devs were\n>> getting error while pushing annotated tags. Since we use Gitolite, we\n>> added the following to gitolite.conf and the tag push worked for them:\n>>\n>> RW+ refs/tags=developer_name\n>>\n>\n> Sounds like you needed to add RW permissions to the refs/tags namespace.\n>\n>> I'm wondering why.\n>>\n>\n> Ok, so normally, pre-receive hook is used to implement policy. Ie:\n> prevent acceptance of pushes that have \"bad\" content as defined by the\n> repository owner. For example, preventing push of tags that don't\n> match some format, or preventing pushes which contain bad stuff.\n>\n> I could provide some examples or suggestions if you would describe\n> what sort of policy you're trying to enforce..\n>\n> git describe will tell you if the commit you're passing it is\n> associated with an annotated tag. I do not understand who this\n> information can help you implement any policy, so understanding what\n> the policy you want is would be the most helpful.\n>\n> I can't really help more or understand exactly what you were doing\n> without understanding what policy you were/are trying to implement.\n>\n> The thing your code is doing today is something like:\n>\n> for each reference update, locate every commit\n>\n> for each commit in this reference update, check to see if it already\n> has an associated tag connected to it.\n>\n> If it doesn't have a tag, then \"do some more checks\" which are not\n> described here.\n>\n> This doesn't make sense to me at all. I think what you *meant* was this:\n>\n> for each reference update, if the reference being updated is a tag, skip it\n>\n> otherwise, for each commit in the reference update do some checks on it.\n>\n> That is *completely* different from the code you've written today.\n>\n> Regards,\n> Jake\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to [hidden email]\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n>\n> ________________________________\n> If you reply to this email, your message will be added to the discussion\n> below:\n> http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764p7635875.html\n> To unsubscribe from Git tag: pre-receive hook issue, click here.\n> NAML\n"},{"id":"266463","messageId":"CA+P7+xqXxYtJiJ4xdYya25NgqrxncWP3rpVMLYBWTbnnA_oynQ@mail.gmail.com","threadId":"39877","inReplyTo":"CAGDgvc1CwmQV75mo22v5LQH4q-kNMFtVq3Y9eSt9LL44JHr5Og@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-07-19T23:35:24Z","receivedAt":"2015-07-19T23:35:24Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"To check whether the ref being updated is a tag, you need to check the\n3rd parameter. pre-receive receives in the format\n\n \n\nso you need to check each line's 3rd value which is the ref-name being\nupdated. If it's in refs/tags then it's a tag update. If it's not, you\ncan check it as a branch update.\n\nThen you should check all new commits for each branch, as Julio mentioned above.\n\nChecking whether each commit has an associated tag is probably not\nwhat you meant.\n\nRegards,\nJake\n\nOn Sun, Jul 19, 2015 at 3:13 AM, Gaurav Chhabra\n wrote:\n> The only thing we wanted to check was whether a ref is a tag. :) Rest\n> other things are working fine (except for the \"commits=$new_sha1\"\n> thing which Junio already pointed out and corrected). I will correct\n> the pre-receive hook.\n>\n> The only mystery that remains is about the current nonsensical code\n> working fine in the past for few annotated tag pushes. It shouldn't\n> have worked just by providing:\n>\n> RW+ refs/tags=developer_name\n>\n> Ref: http://gitolite.com/gitolite/g2/aac.html (Section: \"deny\" rules\n> for refs in a repo)\n>\n>\n> On Sun, Jul 19, 2015 at 2:09 PM, Jacob Keller [via git]\n> wrote:\n>> On Sun, Jul 19, 2015 at 12:55 AM, Gaurav Chhabra\n>> <[hidden email]> wrote:\n>>> @Junio: So from your detailed explanation (and Jake's comment), i\n>>> understand that since my ref wasn't updated on remote so querying the\n>>> same using \"git describe\" resulted in failure, and hence, code was not\n>>> entering the IF block. Correct?\n>>>\n>>\n>> I assume so.\n>>\n>>> Also, while i was reading your replies, i was just thinking that the\n>>> following question that i asked Jake doesn't really make sense because\n>>> a commit object _is_ being passed (on local machine) to \"git\n>>> describe\", which is what it expects so it should work for sure:\n>>>\n>>\n>> It works yes. Git describe finds the nearest tag. --exact-match fails\n>> unless it can find a tag at the commit specified.\n>>\n>>> \"If i got the above right, then shouldn't Git throw an error even on\n>>> my local machine when i'm running \"git describe --exact-match\n>>> ac28ca721e67a\"?\"\n>>>\n>>\n>> only if ac28ca721e67a does not have an annotated tag associated to it\n>>\n>>\n>>\n>>> @Junio: You wrote: \"The part that I find questionable is that by\n>>> checking with \"is this commit a tagged one?\" and doing different\n>>> things. What makes the initial and the third special to deserve\n>>> checking (because they are not annotated with a tag) while skipping\n>>> the validation for the second (merely because it has an annotated tag\n>>> added to it)?\"\n>>>> Isn't the code that i shared doing just the opposite of what you've\n>>>> written? It's checking for annotated tags only and skipping the lightweight\n>>>> ones (although it shouldn't be doing all such things in the first place).\n>>>> Was it a typo on your part?\n>>>\n>>>\n>>\n>> I'm not sure what the code you have is trying to do. See below.\n>>\n>>> @Jake: For the question you asked: \"It would help a lot if we\n>>> understood exactly what you are trying to accomplish.\"\n>>>> I'm not sure how my colleague zeroed in on this \"git describe\" command\n>>>> but i at least know what we observed (and 'seemed' to work). We saw that if\n>>>> we use git-describe and pass a commit object, it throws fatal error message.\n>>>> On the other hand, if we pass a tag object, it doesn't throw any fatal\n>>>> error. That's the reason he added that tag check portion.\n>>>\n>>\n>> Hmmm....\n>>\n>>>\n>>> @Junio/Jake: After going through all the responses that i've received\n>>> so far on this forum, i'm thinking how this nonsense code worked for\n>>> few cases in the past? When this check was put in place, devs were\n>>> getting error while pushing annotated tags. Since we use Gitolite, we\n>>> added the following to gitolite.conf and the tag push worked for them:\n>>>\n>>> RW+ refs/tags=developer_name\n>>>\n>>\n>> Sounds like you needed to add RW permissions to the refs/tags namespace.\n>>\n>>> I'm wondering why.\n>>>\n>>\n>> Ok, so normally, pre-receive hook is used to implement policy. Ie:\n>> prevent acceptance of pushes that have \"bad\" content as defined by the\n>> repository owner. For example, preventing push of tags that don't\n>> match some format, or preventing pushes which contain bad stuff.\n>>\n>> I could provide some examples or suggestions if you would describe\n>> what sort of policy you're trying to enforce..\n>>\n>> git describe will tell you if the commit you're passing it is\n>> associated with an annotated tag. I do not understand who this\n>> information can help you implement any policy, so understanding what\n>> the policy you want is would be the most helpful.\n>>\n>> I can't really help more or understand exactly what you were doing\n>> without understanding what policy you were/are trying to implement.\n>>\n>> The thing your code is doing today is something like:\n>>\n>> for each reference update, locate every commit\n>>\n>> for each commit in this reference update, check to see if it already\n>> has an associated tag connected to it.\n>>\n>> If it doesn't have a tag, then \"do some more checks\" which are not\n>> described here.\n>>\n>> This doesn't make sense to me at all. I think what you *meant* was this:\n>>\n>> for each reference update, if the reference being updated is a tag, skip it\n>>\n>> otherwise, for each commit in the reference update do some checks on it.\n>>\n>> That is *completely* different from the code you've written today.\n>>\n>> Regards,\n>> Jake\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to [hidden email]\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>>\n>>\n>> ________________________________\n>> If you reply to this email, your message will be added to the discussion\n>> below:\n>> http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764p7635875.html\n>> To unsubscribe from Git tag: pre-receive hook issue, click here.\n>> NAML\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"266484","messageId":"CAGDgvc08ZMdKH-6FdtYWXCBbiX=UYdKTTKVtEF65J+jW5mDYCA@mail.gmail.com","threadId":"39877","inReplyTo":"CA+P7+xqXxYtJiJ4xdYya25NgqrxncWP3rpVMLYBWTbnnA_oynQ@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Gaurav Chhabra","fromEmail":"varuag.chhabra@gmail.com","sentAt":"2015-07-20T07:43:33Z","receivedAt":"2015-07-20T07:43:33Z","isPatch":false,"sender":{"key":"varuag.chhabra@gmail.com","avatar":"https://gravatar.com/avatar/b731428347fdc09c456902cac39c52957f1e296e8edd38f6162400e8402f480e?d=mp&s=160"},"body":"Hi Jake,\n\nThanks about the refs/tags check. I’m aware about this. Junio also\nexplained it in one of his replies. I was actually confused why my\ncurrent code was working in past for few of the annotated tags.\nAnyways, now that I have clarity about the mistake in the code, I\nguess, I’ll figure it out myself.\n\n@Junio: Thanks a lot for your detailed explanation about the ‘behind\nthe scenes’ activity during a push process. That was definitely\nhelpful and will help me in future too.\n\n@Jake: Thanks for your help and your patience in explaining things.\n\n\n\nOn Mon, Jul 20, 2015 at 5:05 AM, Jacob Keller [via git]\n wrote:\n> To check whether the ref being updated is a tag, you need to check the\n> 3rd parameter. pre-receive receives in the format\n>\n> \n>\n> so you need to check each line's 3rd value which is the ref-name being\n> updated. If it's in refs/tags then it's a tag update. If it's not, you\n> can check it as a branch update.\n>\n> Then you should check all new commits for each branch, as Julio mentioned\n> above.\n>\n> Checking whether each commit has an associated tag is probably not\n> what you meant.\n>\n> Regards,\n> Jake\n>\n> On Sun, Jul 19, 2015 at 3:13 AM, Gaurav Chhabra\n> <[hidden email]> wrote:\n>\n>> The only thing we wanted to check was whether a ref is a tag. :) Rest\n>> other things are working fine (except for the \"commits=$new_sha1\"\n>> thing which Junio already pointed out and corrected). I will correct\n>> the pre-receive hook.\n>>\n>> The only mystery that remains is about the current nonsensical code\n>> working fine in the past for few annotated tag pushes. It shouldn't\n>> have worked just by providing:\n>>\n>> RW+ refs/tags=developer_name\n>>\n>> Ref: http://gitolite.com/gitolite/g2/aac.html (Section: \"deny\" rules\n>> for refs in a repo)\n>>\n>>\n>> On Sun, Jul 19, 2015 at 2:09 PM, Jacob Keller [via git]\n>> <[hidden email]> wrote:\n>>> On Sun, Jul 19, 2015 at 12:55 AM, Gaurav Chhabra\n>>> <[hidden email]> wrote:\n>>>> @Junio: So from your detailed explanation (and Jake's comment), i\n>>>> understand that since my ref wasn't updated on remote so querying the\n>>>> same using \"git describe\" resulted in failure, and hence, code was not\n>>>> entering the IF block. Correct?\n>>>>\n>>>\n>>> I assume so.\n>>>\n>>>> Also, while i was reading your replies, i was just thinking that the\n>>>> following question that i asked Jake doesn't really make sense because\n>>>> a commit object _is_ being passed (on local machine) to \"git\n>>>> describe\", which is what it expects so it should work for sure:\n>>>>\n>>>\n>>> It works yes. Git describe finds the nearest tag. --exact-match fails\n>>> unless it can find a tag at the commit specified.\n>>>\n>>>> \"If i got the above right, then shouldn't Git throw an error even on\n>>>> my local machine when i'm running \"git describe --exact-match\n>>>> ac28ca721e67a\"?\"\n>>>>\n>>>\n>>> only if ac28ca721e67a does not have an annotated tag associated to it\n>>>\n>>>\n>>>\n>>>> @Junio: You wrote: \"The part that I find questionable is that by\n>>>> checking with \"is this commit a tagged one?\" and doing different\n>>>> things. What makes the initial and the third special to deserve\n>>>> checking (because they are not annotated with a tag) while skipping\n>>>> the validation for the second (merely because it has an annotated tag\n>>>> added to it)?\"\n>>>>> Isn't the code that i shared doing just the opposite of what you've\n>>>>> written? It's checking for annotated tags only and skipping the\n>>>>> lightweight\n>>>>> ones (although it shouldn't be doing all such things in the first\n>>>>> place).\n>>>>> Was it a typo on your part?\n>>>>\n>>>>\n>>>\n>>> I'm not sure what the code you have is trying to do. See below.\n>>>\n>>>> @Jake: For the question you asked: \"It would help a lot if we\n>>>> understood exactly what you are trying to accomplish.\"\n>>>>> I'm not sure how my colleague zeroed in on this \"git describe\" command\n>>>>> but i at least know what we observed (and 'seemed' to work). We saw\n>>>>> that if\n>>>>> we use git-describe and pass a commit object, it throws fatal error\n>>>>> message.\n>>>>> On the other hand, if we pass a tag object, it doesn't throw any fatal\n>>>>> error. That's the reason he added that tag check portion.\n>>>>\n>>>\n>>> Hmmm....\n>>>\n>>>>\n>>>> @Junio/Jake: After going through all the responses that i've received\n>>>> so far on this forum, i'm thinking how this nonsense code worked for\n>>>> few cases in the past? When this check was put in place, devs were\n>>>> getting error while pushing annotated tags. Since we use Gitolite, we\n>>>> added the following to gitolite.conf and the tag push worked for them:\n>>>>\n>>>> RW+ refs/tags=developer_name\n>>>>\n>>>\n>>> Sounds like you needed to add RW permissions to the refs/tags namespace.\n>>>\n>>>> I'm wondering why.\n>>>>\n>>>\n>>> Ok, so normally, pre-receive hook is used to implement policy. Ie:\n>>> prevent acceptance of pushes that have \"bad\" content as defined by the\n>>> repository owner. For example, preventing push of tags that don't\n>>> match some format, or preventing pushes which contain bad stuff.\n>>>\n>>> I could provide some examples or suggestions if you would describe\n>>> what sort of policy you're trying to enforce..\n>>>\n>>> git describe will tell you if the commit you're passing it is\n>>> associated with an annotated tag. I do not understand who this\n>>> information can help you implement any policy, so understanding what\n>>> the policy you want is would be the most helpful.\n>>>\n>>> I can't really help more or understand exactly what you were doing\n>>> without understanding what policy you were/are trying to implement.\n>>>\n>>> The thing your code is doing today is something like:\n>>>\n>>> for each reference update, locate every commit\n>>>\n>>> for each commit in this reference update, check to see if it already\n>>> has an associated tag connected to it.\n>>>\n>>> If it doesn't have a tag, then \"do some more checks\" which are not\n>>> described here.\n>>>\n>>> This doesn't make sense to me at all. I think what you *meant* was this:\n>>>\n>>> for each reference update, if the reference being updated is a tag, skip\n>>> it\n>>>\n>>> otherwise, for each commit in the reference update do some checks on it.\n>>>\n>>> That is *completely* different from the code you've written today.\n>>>\n>>> Regards,\n>>> Jake\n>>> --\n>>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>>> the body of a message to [hidden email]\n>>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>>>\n>>>\n>>> ________________________________\n>>> If you reply to this email, your message will be added to the discussion\n>>> below:\n>>>\n>>> http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764p7635875.html\n>>> To unsubscribe from Git tag: pre-receive hook issue, click here.\n>>> NAML\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to [hidden email]\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to [hidden email]\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n>\n> ________________________________\n> If you reply to this email, your message will be added to the discussion\n> below:\n> http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764p7635968.html\n> To unsubscribe from Git tag: pre-receive hook issue, click here.\n> NAML\n"},{"id":"266491","messageId":"1437408165.11638.3.camel@intel.com","threadId":"39877","inReplyTo":"CAGDgvc08ZMdKH-6FdtYWXCBbiX=UYdKTTKVtEF65J+jW5mDYCA@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Keller, Jacob E","fromEmail":"jacob.e.keller@intel.com","sentAt":"2015-07-20T16:02:45Z","receivedAt":"2015-07-20T16:02:45Z","isPatch":false,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Mon, 2015-07-20 at 13:13 +0530, Gaurav Chhabra wrote:\n> Hi Jake,\n> \n> Thanks about the refs/tags check. I’m aware about this. Junio also\n> explained it in one of his replies. I was actually confused why my\n> current code was working in past for few of the annotated tags.\n> Anyways, now that I have clarity about the mistake in the code, I\n> guess, I’ll figure it out myself.\n> \n> @Junio: Thanks a lot for your detailed explanation about the ‘behind\n> the scenes’ activity during a push process. That was definitely\n> helpful and will help me in future too.\n> \n> @Jake: Thanks for your help and your patience in explaining things.\n> \n\nNo problem. I'm also not certain why it would have worked in some\ncases, so that is definitely confusing, but at least you can get it\nsorted to do what you intend. Best of luck!\n\nRegards,\nJake"},{"id":"266628","messageId":"55AFF324.2000609@gmail.com","threadId":"39877","inReplyTo":"CA+P7+xpevvV=5QdfBdzcD=8=2ff+m-kzxX-w1wLME8oRyn8QBA@mail.gmail.com","subject":"Re: Git tag: pre-receive hook issue","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2015-07-22T19:46:44Z","receivedAt":"2015-07-22T19:46:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 2015-07-19, Jacob Keller wrote:\n\n> git describe will tell you if the commit you're passing it is\n> associated with an annotated tag. I do not understand who this\n> information can help you implement any policy, so understanding what\n> the policy you want is would be the most helpful.\n\nOne policy I can think of that may have use of checking if commit\nis tagged is requiring some extra restrictions on the commit that\nis being tagged, for example that the only file that it can touch\nis version.h / VERSION-FILE, and no code changes at all.\n\n-- \nJakub Narębski\n"}]}