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

Re: Git tag: pre-receive hook issue

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 17, 2015, 19:30 UTC
Message-ID
<xmqqoaja1t0y.fsf@gitster.dls.corp.google.com>
In-Reply-To
<1437159533304-7635764.post@n2.nabble.com>
Garbageyard <varuag.chhabra@gmail.com> writes:
Show 11 quoted lines
> We have a pre-receive hook that checks for JIRA ID whenever someone pushes
> code to Git server. I'm trying to avoid this check when someone is applying
> a tag. Here's the link for the script: http://pastebin.com/VnMQp5ar
>
> This is the link for output: http://pastebin.com/tBGmYaZF
>
> Problem is that if i run the following command, the output that i get on
> command line is 0
>
> git describe --exact-match ac28ca721e67adc04078786164939989a5112d98 2>&1 |
> grep -o fatal | wc -w
I am not sure what you are trying to do in the first place.
  : gitster x; git init garbage
  Initialized empty Git repository in /var/tmp/x/garbage/.git/
  : gitster x; cd garbage
  : gitster garbage/master; git commit --allow-empty -m initial
  [master (root-commit) b18cac2] initial
  : gitster garbage/master; git tag v0.0 ;# lightweight
  : gitster garbage/master; git commit --allow-empty -m second
  [master d1de78e] second
  : gitster garbage/master; git tag -a 'v0.1' v0.1
  fatal: Failed to resolve 'v0.1' as a valid ref.
  : gitster garbage/master; git tag -a -m 'v0.1' v0.1
  : gitster garbage/master; git commit --allow-empty -m third
  [master d1f1360] third
  : gitster garbage/master; git describe --exact-match HEAD ;# third
  fatal: no tag exactly matches 'd1f1360b46dfde8c6f341e48ce45d761ed37e357'
  : gitster garbage/master; git describe --exact-match HEAD^ ;# second
  v0.1
  : gitster garbage/master; git describe --exact-match HEAD^^ ;# first
  fatal: no tag exactly matches 'b18cac237055d9518f9f92bb4c0a4dac825dce17'
  : gitster garbage/master; exit

I am feeding three _commits_, not tags. But one of them (i.e. the one that happens to have an annotated tag) yields the "exact match" tagname, as designed and expected.

But is it really what you want to do to skip such a commit?  Why?
I also see a questionable thing in the earlier part of your script:
   while read old_sha1 new_sha1 refname ; do
           echo "stdin: [$old_sha1] [$new_sha1] [$refname]"
           if [ "$old_sha1" == "0000000000000000000000000000000000000000" ] ; then
               commits=$new_sha1
           else
               commits=`git rev-list $old_sha1..$new_sha1`
           fi
           for commit in $commits
           do
		...

When somebody pushes to an existing branch, you list all the new commits that came in (i.e. 'git rev-list' is bounded by $old_sha1 at the bottom). But when somebody pushes to a new branch, you only include the tip to the list.

And you check everything on that list. Why? If I push three-commit series to a new branch, wouldn't you want to validate all three of them, just like you validate my push of a three-commit enhancement to an existing branch?

	while read old new name
        do
		case "$name" in refs/heads/tags/*) continue ;; esac
		if test "$old" = 0000000000000000000000000000000000000000
		then
			git rev-list $old
		else
                	git rev-list $old..$new
		fi
	done |
	while read commit
        do
        	Do a check on $commit
	done
or something instead?
Previous: GarbageyardNext: Jacob Keller
Message 2 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.