Re: Git tag: pre-receive hook issue

[Jacob Keller <jacob.keller@gmail.com>]

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
<varuag.chhabra@gmail.com> 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]
> <ml-node+s661346n7635875h48@n2.nabble.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html