On Oct 13, 2007, at 5:21 AM, Shawn O. Pearce wrote:
Steffen Prohaska <prohaska@xxxxxx> wrote:
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?
I think its a bug. But I didn't write the original code.
Meaning I think what happened here was someone wanted to enable
git-send-pack to match "master" here with "refs/heads/master" on
the remote side. One easy way to do that was to see if any ref
ended with "/master", as that was what the ref here was called.
Way back when that code was written most Git repositories probably
only ever had that one branch anyway, or maybe two (refs/heads/master
and refs/heads/origin) so matching the trailing suffix never came
up as a bug. Nobody ever had two refs that could possibly match.
Then the documentation got expanded to actually document the behavior
that git-send-pack implemented. Unfortunately that codified the
bug as documented behavior.
So I agree with you Steffen, this is a bug in send-pack, and I run
up against it every once in a while. I've specifically told my
coworkers "NEVER, EVER, EVER, create a branch called 'master' that
isn't exactly refs/heads/master OR ELSE I WILL COME BEAT YOU WITH A
CLUE STICK". They still create "refs/heads/experiments/master".
*sigh*.
I think we should fix it. Anyone that is relying on "git push
$url master" to resolve to "refs/heads/experimental/master" on the
remote side is already playing with fire. But Junio is (rightfully
so) very conservative and doesn't like to break a user's scripts.
We may not be able to fix this until Git 1.6.
I'm working on this and will send patches tomorrow.
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
