git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: push fails with unexpected 'matches more than one'

From
Shawn O. Pearce <spearce@spearce.org>
Date
Oct 13, 2007, 03:21 UTC
Message-ID
<20071013032100.GK27899@spearce.org>
In-Reply-To
<91A04390-89B2-47B8-9B61-7C7E652670AE@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
Show 17 quoted lines
> 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.
Previous: Steffen ProhaskaNext: Steffen Prohaska
Message 3 of 4 in “push fails with unexpected 'matches more than one'”
  1. Steffen ProhaskaOct 12, 2007
  2. Steffen ProhaskaOct 12, 2007
  3. Shawn O. PearceOct 13, 2007
  4. Steffen ProhaskaOct 13, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.