From: "Shawn O. Pearce" <spearce@spearce.org>
To: Steffen Prohaska <prohaska@zib.de>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: push fails with unexpected 'matches more than one'
Date: Fri, 12 Oct 2007 23:21:00 -0400 [thread overview]
Message-ID: <20071013032100.GK27899@spearce.org> (raw)
In-Reply-To: <91A04390-89B2-47B8-9B61-7C7E652670AE@zib.de>
Steffen Prohaska <prohaska@zib.de> 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.
--
Shawn.
next prev parent reply other threads:[~2007-10-13 3:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-12 6:59 push fails with unexpected 'matches more than one' Steffen Prohaska
2007-10-12 12:06 ` Steffen Prohaska
2007-10-13 3:21 ` Shawn O. Pearce [this message]
2007-10-13 16:51 ` Steffen Prohaska
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071013032100.GK27899@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=prohaska@zib.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox