On Sun, Jul 19, 2015 at 12:55 AM, Gaurav Chhabra <varuag.chhabra@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html