Hi Jan,

Thank you for the detailed report. Sorry it's taken so long to get to it. I have modified the update hook to use --abbrev=0 rather than the sed 's/-g//', as Joshua noted. This change was made to the upstream git update hook shortly after the fedora hook was setup on the hosted servers.

Please let us know if you have any trouble with this.

Longer term, I think we should follow upstream's lead and move the mail notification from the update hook to the post-receive hook. I've started a discussion about this on the fedora-infrastructure-list:

http://www.redhat.com/archives/fedora-infrastructure-list/2009-June/msg00160.html

Hello,

while the change helped a bit, it did not resolve the issue fully. The error message now is

$ git push --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 234 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
fatal: Invalid revision range
0000000000000000000000000000000000000000..9819b729122602f79cf144954f7f0e478e9622dd
To ssh://msuchy@git.fedorahosted.org/git/spacewalk.git/
* [new tag] spacewalk-proxy-installer-0.6.16-1 -> spacewalk-proxy-installer-0.6.16-1

So while the bogus tag name is gone, there still seems to be something going on, looking at the 000...000 (which I read as missing, or none) SHA1. Could you please investigate?

Hi Jan,

Sorry that wasn't the only bug you're hitting the update hook. I'll dig more and try to find a fix.

Hi Jan,

Looking over the update hook, I'm not sure where the 0000000 ref is coming from. The hook checks for that before using the oldref. It could happen if there was a ref being deleted, but the error seems to indicate that the oldref is 0000000 and the newref is 9819b72. Without seeing exactly what is passed by git to the update hook, I'm a bit at a loss.

I have a few things we might try though. One would be to add set -x to the top of the update hook. That would let us see the full output of the hook being run. The downside is that it would cause a lot of text to spew onto anyone's screen that did a push while we had this enabled. So we'd want to coordinate something like that. I'm generally on freenode as tmz, if you wanted to try that, ping me and we'll see if we can't find a time to test this quick. (I usually keep mildly late hours on EDT.)

Another option, which might be better in the long run anyway, would be to ditch the current update hook and use the hook we're now using for the Fedora Infrastructure Puppet repo. We borrowed the hook from the gnome.org folks. Example output of this can be found in the gnome.org commits list: http://mail.gnome.org/archives/svn-commits-list/

I tested this a bit with Devan Goodwin (dgoodwin) today and we couldn't reproduce the error. We've left the update hook with set -x enabled and Devan was going to let other spacewalk devs know to expect the extra output and save it if it contains evidence of the 'fatal: Invalid revision range' error.

(For other infra team members, what I've done is to copy /usr/bin/fedora-git-commit-mail-hook to /usr/bin/fedora-git-commit-mail-hook.spacewalk, added a set -x call at the top, and pointed the /git/spacewalk.git/hooks/update symlink at the new script.)

A user on our mailing list points out it's actually the pre-receive hook that we disabled yesterday: https://www.redhat.com/archives/spacewalk-devel/2009-July/msg00090.html

Which explains why we couldn't reproduce it.

I'm going to propose to the team that we keep it disabled as I don't think it's buying us anything but pain right now.

Please feel free to disable the set -x output. Thanks!

Done. Let us know if/when you want to update and enable to pre-receive hook. Thanks guys, happy hacking!