On Oct 12, 2007, at 8:59 AM, Steffen Prohaska wrote:
This adds a test case for unambigous local match but multiple remote
matches. To me, it is unexpected that a ref that is perfectly defined
on the local side fails with 'matches more than one'.
The following rule could solve this:
A ref shall first be unambigously resolved on the local side, and its
full name should be used for matching on the remote side.
For example 'frotz' resolves locally to 'heads/refs/frotz'.
Therefore pretend the user had typed 'heads/refs/frotz'.
But maybe there is some hidden secret about the current rules that
I do not see.
Here is a related question:
I read carefully through the documentation of git-send-pack and
git-rev-parse. The current implementation of git-send-pack is in line
with the documented behaviour, as is the implementation of git-rev-
parse.
So formally everything is correct.
But it is completely against my expectation that git-push <remote>
<head>
can successfully resolve a <head> that git-rev-parse fails to parse. I
understand that refs are not revs ;). But nonetheless, I'd expect that a
local ref that cannot be parsed by git-rev-parse should also fail to be
pushed by git-send-pack. I didn't expect that git-send-pack would locate
<head> as someprefix/<head>.
Why is my expectation wrong?
Or is the current specification of git-send-pack's ref parsing wrong?
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
