Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upFix creating references containing '@' #854
Conversation
References containing the '@' char are legal in git but fail with
[1]. This fails because as soon as '@' is encountered we stop
searching for a ref name, assume it is there and fail while retrieving
it. This can be fixed by catching this exception and continue with the
search for a valid ref.
[1] Trace:
Traceback (most recent call last):
File "/opt/zuul/lib/python3.7/site-packages/zuul/merger/merger.py", line 108, in __init__
self._ensure_cloned()
File "/opt/zuul/lib/python3.7/site-packages/zuul/merger/merger.py", line 178, in _ensure_cloned
repo.create_head(ref.remote_head, ref, force=True)
File "/opt/zuul/lib/python3.7/site-packages/git/repo/base.py", line 373, in create_head
return Head.create(self, path, commit, force, logmsg)
File "/opt/zuul/lib/python3.7/site-packages/git/refs/symbolic.py", line 546, in create
return cls._create(repo, path, cls._resolve_ref_on_create, reference, force, logmsg)
File "/opt/zuul/lib/python3.7/site-packages/git/refs/symbolic.py", line 497, in _create
target = repo.rev_parse(str(reference))
File "/opt/zuul/lib/python3.7/site-packages/git/repo/fun.py", line 211, in rev_parse
ref = name_to_object(repo, rev[:start], return_ref=True)
File "/opt/zuul/lib/python3.7/site-packages/git/repo/fun.py", line 142, in name_to_object
raise BadObject("Couldn't find reference named %r" % name)
gitdb.exc.BadObject: <unprintable BadObject object>
|
Thanks a lot for the contribution! Do you think it's possible to have another look? |
| @@ -208,7 +208,14 @@ def rev_parse(repo, rev): | |||
| ref = repo.head.ref | |||
| else: | |||
| if token == '@': | |||
| ref = name_to_object(repo, rev[:start], return_ref=True) | |||
| try: | |||
Byron
Jul 20, 2019
Member
A better solution might be to stop treating @ as special outside of the spots that it is allowed in.
I am a hesitant to let it make assumptions unless there absolutely is no other way. Or in other words, I believe the git or C implementation is deterministic here
A better solution might be to stop treating @ as special outside of the spots that it is allowed in.
I am a hesitant to let it make assumptions unless there absolutely is no other way. Or in other words, I believe the git or C implementation is deterministic here
tobiashenkel
Aug 8, 2019
Author
Thanks for your feedback, I'll try it when I have time in the next weeks.
Thanks for your feedback, I'll try it when I have time in the next weeks.
|
Ping - any updates? The changes here work for me and the situation I've run into this with. It would be nice to see this (or a better solution) merged. |
|
Having had a look at it again, I still feel uneasy about making an assumption warranting this comment:
I wonder if it's safe that way, or if it leaves us open to causing unexpected breakage. Maybe @Harmon758 can provide their opinion on this - generally this PR seems like a very desirable fix. |
References containing the '@' char are legal in git but fail with
[1]. This fails because as soon as '@' is encountered we stop
searching for a ref name, assume it is there and fail while retrieving
it. This can be fixed by catching this exception and continue with the
search for a valid ref.