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

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 12, 2007, 12:06 UTC
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:

Show 12 quoted lines

> 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