Repository navigation
FetchInfo.commit breaks if you fetch a tag to anywhere but refs/tags/ #24
Description
As an example, use a refspec of refs/*:refs/remotes/origin/*. Behavior:
File "/home/kergoth/.local/lib/python2.6/site-packages/git/refs/tag.py", line 26, in commit
obj = self.object
File "/home/kergoth/.local/lib/python2.6/site-packages/git/refs/symbolic.py", line 158, in _get_object
return Object.new_from_sha(self.repo, hex_to_bin(self.dereference_recursive(self.repo, self.path)))
File "/home/kergoth/.local/lib/python2.6/site-packages/git/refs/symbolic.py", line 112, in dereference_recursive
hexsha, ref_path = cls._get_ref_info(repo, ref_path)
File "/home/kergoth/.local/lib/python2.6/site-packages/git/refs/symbolic.py", line 139, in _get_ref_info
raise ValueError("Reference at %r does not exist" % ref_path)
ValueError: Reference at 'refs/tags/766da90/tags/1.0' does not exist
I'd guess there's an implicit assumption that a tag lives in refs/tags/, and the ref path is reconstructed based on that rather than using the correct ref path which the code has already (refs/remotes/766da90/tags/1.0).
Activity
Fetch info can now deal much better with non-default ref specs, see #23…
kergoth commentedon Jul 15, 2011
This one still breaks, but in a different way, with a new message:
File "/home/kergoth/.local/lib/python2.7/site-packages/GitPython-0.3.1-py2.7.egg/git/refs/symbolic.py", line 177, in _get_object_sha
return hex_to_bin(self.dereference_recursive(self.repo, self.path))
File "/home/kergoth/.local/lib/python2.7/site-packages/GitPython-0.3.1-py2.7.egg/git/refs/symbolic.py", line 133, in dereference_recursive
hexsha, ref_path = cls._get_ref_info(repo, ref_path)
File "/home/kergoth/.local/lib/python2.7/site-packages/GitPython-0.3.1-py2.7.egg/git/refs/symbolic.py", line 160, in _get_ref_info
raise ValueError("Reference at %r does not exist" % ref_path)
ValueError: Reference at 'refs/remotes/1.0' does not exist
Byron commentedon Nov 19, 2014
Similar or duplicate of #28
Byron commentedon Jan 8, 2015
gitpython now properly deduces tags, which fixed #28 . It's kind of an assumption to believe this issue is fixed as well, but I hope you will be able to retest it with the latest version on pypi to verify it.
Personally, I am optimistic that it works now and have no reason to assume this case isn't properly handled.
If you come up with anything, please feel free to post it here and I will reopen the issue.