Hi Jake, Thanks about the refs/tags check. I’m aware about this. Junio also explained it in one of his replies. I was actually confused why my current code was working in past for few of the annotated tags. Anyways, now that I have clarity about the mistake in the code, I guess, I’ll figure it out myself. @Junio: Thanks a lot for your detailed explanation about the ‘behind the scenes’ activity during a push process. That was definitely helpful and will help me in future too. @Jake: Thanks for your help and your patience in explaining things. On Mon, Jul 20, 2015 at 5:05 AM, Jacob Keller [via git] <ml-node+s661346n7635968h31@xxxxxxxxxxxxx> wrote: > To check whether the ref being updated is a tag, you need to check the > 3rd parameter. pre-receive receives in the format > > <old-value> <new-value> <ref-name> > > so you need to check each line's 3rd value which is the ref-name being > updated. If it's in refs/tags then it's a tag update. If it's not, you > can check it as a branch update. > > Then you should check all new commits for each branch, as Julio mentioned > above. > > Checking whether each commit has an associated tag is probably not > what you meant. > > Regards, > Jake > > On Sun, Jul 19, 2015 at 3:13 AM, Gaurav Chhabra > <[hidden email]> wrote: > >> The only thing we wanted to check was whether a ref is a tag. :) Rest >> other things are working fine (except for the "commits=$new_sha1" >> thing which Junio already pointed out and corrected). I will correct >> the pre-receive hook. >> >> The only mystery that remains is about the current nonsensical code >> working fine in the past for few annotated tag pushes. It shouldn't >> have worked just by providing: >> >> RW+ refs/tags=developer_name >> >> Ref: http://gitolite.com/gitolite/g2/aac.html (Section: "deny" rules >> for refs in a repo) >> >> >> On Sun, Jul 19, 2015 at 2:09 PM, Jacob Keller [via git] >> <[hidden email]> wrote: >>> On Sun, Jul 19, 2015 at 12:55 AM, Gaurav Chhabra >>> <[hidden email]> wrote: >>>> @Junio: So from your detailed explanation (and Jake's comment), i >>>> understand that since my ref wasn't updated on remote so querying the >>>> same using "git describe" resulted in failure, and hence, code was not >>>> entering the IF block. Correct? >>>> >>> >>> I assume so. >>> >>>> Also, while i was reading your replies, i was just thinking that the >>>> following question that i asked Jake doesn't really make sense because >>>> a commit object _is_ being passed (on local machine) to "git >>>> describe", which is what it expects so it should work for sure: >>>> >>> >>> It works yes. Git describe finds the nearest tag. --exact-match fails >>> unless it can find a tag at the commit specified. >>> >>>> "If i got the above right, then shouldn't Git throw an error even on >>>> my local machine when i'm running "git describe --exact-match >>>> ac28ca721e67a"?" >>>> >>> >>> only if ac28ca721e67a does not have an annotated tag associated to it >>> >>> >>> >>>> @Junio: You wrote: "The part that I find questionable is that by >>>> checking with "is this commit a tagged one?" and doing different >>>> things. What makes the initial and the third special to deserve >>>> checking (because they are not annotated with a tag) while skipping >>>> the validation for the second (merely because it has an annotated tag >>>> added to it)?" >>>>> 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? >>>> >>>> >>> >>> I'm not sure what the code you have is trying to do. See below. >>> >>>> @Jake: For the question you asked: "It would help a lot if we >>>> understood exactly what you are trying to accomplish." >>>>> 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. >>>> >>> >>> Hmmm.... >>> >>>> >>>> @Junio/Jake: After going through all the responses that i've received >>>> so far on this forum, i'm thinking how this nonsense code worked for >>>> few cases in the past? When this check was put in place, devs were >>>> getting error while pushing annotated tags. Since we use Gitolite, we >>>> added the following to gitolite.conf and the tag push worked for them: >>>> >>>> RW+ refs/tags=developer_name >>>> >>> >>> Sounds like you needed to add RW permissions to the refs/tags namespace. >>> >>>> I'm wondering why. >>>> >>> >>> Ok, so normally, pre-receive hook is used to implement policy. Ie: >>> prevent acceptance of pushes that have "bad" content as defined by the >>> repository owner. For example, preventing push of tags that don't >>> match some format, or preventing pushes which contain bad stuff. >>> >>> I could provide some examples or suggestions if you would describe >>> what sort of policy you're trying to enforce.. >>> >>> git describe will tell you if the commit you're passing it is >>> associated with an annotated tag. I do not understand who this >>> information can help you implement any policy, so understanding what >>> the policy you want is would be the most helpful. >>> >>> I can't really help more or understand exactly what you were doing >>> without understanding what policy you were/are trying to implement. >>> >>> The thing your code is doing today is something like: >>> >>> for each reference update, locate every commit >>> >>> for each commit in this reference update, check to see if it already >>> has an associated tag connected to it. >>> >>> If it doesn't have a tag, then "do some more checks" which are not >>> described here. >>> >>> This doesn't make sense to me at all. I think what you *meant* was this: >>> >>> for each reference update, if the reference being updated is a tag, skip >>> it >>> >>> otherwise, for each commit in the reference update do some checks on it. >>> >>> That is *completely* different from the code you've written today. >>> >>> Regards, >>> Jake >>> -- >>> To unsubscribe from this list: send the line "unsubscribe git" in >>> the body of a message to [hidden email] >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >>> ________________________________ >>> If you reply to this email, your message will be added to the discussion >>> below: >>> >>> http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764p7635875.html >>> To unsubscribe from Git tag: pre-receive hook issue, click here. >>> NAML >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to [hidden email] >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to [hidden email] > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > ________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://git.661346.n2.nabble.com/Git-tag-pre-receive-hook-issue-tp7635764p7635968.html > To unsubscribe from Git tag: pre-receive hook issue, click here. > NAML -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html