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+s661346n7635875...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
