From: Steffen Prohaska <prohaska@zib.de>
Date: Fri, 12 Oct 2007 12:06:24 GMT
Subject: Re: push fails with unexpected 'matches more than one'
Message-ID: <91A04390-89B2-47B8-9B61-7C7E652670AE@zib.de>
In-Reply-To: <11921723791817-git-send-email-prohaska@zib.de>


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