Re: Git tag: pre-receive hook issue

[Gaurav Chhabra <varuag.chhabra@gmail.com>]

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