#1362 Errors when pushing tags
Closed: Fixed None Opened 10 years ago by adelton.


in our Spacewalk git repository, we seem to be getting errors like

fatal: ambiguous argument 'spacewalk-java-0.6.1-1-11..2b31b47d57bd0024deb6a7097f1388e3fa0e13ee': unknown revision or path not in the working tree.

-- see threads at



Note that most of our tags have rpm-ish %{name}-%{version}-%{release}, so there actually is a tag spacewalk-java-0.6.1-1; but no spacewalk-java-0.6.1-1-1.

In https://www.redhat.com/archives/spacewalk-devel/2009-April/msg00088.html and https://www.redhat.com/archives/spacewalk-devel/2009-April/msg00089.html, Joshua suggests that the problem is in the use of git describe in fedora-git-commit-mail-hook. Could you check that it's what Spacewalk git repo uses for mail notifications? They have been setup (to spacewalk-commits mailing list) on March 27 and I've first reported it on April 3, so there indeed is a time coincidence.

For the Spacewalk project, the git rev-list in the refs/tags/* case is probably not needed not useful anyway because we have multiple packages in that repository, and showing differences from the last tag (which will most likely be tag belonging to different package) is not that useful. So that part can be commented out for Spacewalk git repo.

Thank you,


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:



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
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!

Login to comment on this ticket.