git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git tag: pre-receive hook issue

From
Gaurav Chhabra <varuag.chhabra@gmail.com>
Date
Jul 19, 2015, 10:13 UTC
Message-ID
<CAGDgvc1CwmQV75mo22v5LQH4q-kNMFtVq3Y9eSt9LL44JHr5Og@mail.gmail.com>
In-Reply-To
<CA+P7+xpevvV=5QdfBdzcD=8=2ff+m-kzxX-w1wLME8oRyn8QBA@mail.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:

Show 117 quoted lines
> 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
Previous: Jacob KellerNext: Jacob Keller
Message 9 of 13 in “Git tag: pre-receive hook issue”
  1. GarbageyardJul 17, 2015
  2. Junio C HamanoJul 17, 2015
  3. Jacob KellerJul 18, 2015
  4. Gaurav ChhabraJul 18, 2015
  5. Junio C HamanoJul 18, 2015
  6. Jacob KellerJul 18, 2015
  7. Gaurav ChhabraJul 19, 2015
  8. Jacob KellerJul 19, 2015
  9. Gaurav ChhabraJul 19, 2015
  10. Jacob KellerJul 19, 2015
  11. Gaurav ChhabraJul 20, 2015
  12. Keller, Jacob EJul 20, 2015
  13. Jakub NarębskiJul 22, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.