# push fails with unexpected 'matches more than one' 4 messages from 2007-10-12 to 2007-10-13. Participants: Steffen Prohaska, Shawn O. Pearce. Thread: https://gitlist.dev/t/10255 ## Steffen Prohaska, 2007-10-12 06:59 Subject: push fails with unexpected 'matches more than one' Message-ID: <11921723791817-git-send-email-prohaska@zib.de> URL: https://gitlist.dev/e/11921723791817-git-send-email-prohaska%40zib.de ``` 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. Signed-off-by: Steffen Prohaska --- t/t5516-fetch-push.sh | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index ca46aaf..f249216 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -244,4 +244,12 @@ test_expect_success 'push with colon-less refspec (4)' ' ' +test_expect_success 'push with colon-less refspec (locally unambigous)' ' + + mk_test heads/frotz heads/t/frotz && + git branch -f frotz master && + git push testrepo frotz + +' + test_done -- 1.5.3.4.219.gd0b2 ``` ## Steffen Prohaska, 2007-10-12 12:06 Subject: Re: push fails with unexpected 'matches more than one' Message-ID: <91A04390-89B2-47B8-9B61-7C7E652670AE@zib.de> URL: https://gitlist.dev/e/91A04390-89B2-47B8-9B61-7C7E652670AE%40zib.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 can successfully resolve a 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 as someprefix/. Why is my expectation wrong? Or is the current specification of git-send-pack's ref parsing wrong? Steffen ``` ## Shawn O. Pearce, 2007-10-13 03:21 Subject: Re: push fails with unexpected 'matches more than one' Message-ID: <20071013032100.GK27899@spearce.org> URL: https://gitlist.dev/e/20071013032100.GK27899%40spearce.org In-Reply-To: <91A04390-89B2-47B8-9B61-7C7E652670AE@zib.de> ``` Steffen Prohaska 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 > > can successfully resolve a 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 > as someprefix/. > > 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. ``` ## Steffen Prohaska, 2007-10-13 16:51 Subject: Re: push fails with unexpected 'matches more than one' Message-ID: URL: https://gitlist.dev/e/CC1A592A-443B-4039-9FA4-2386066C22AD%40zib.de In-Reply-To: <20071013032100.GK27899@spearce.org> ``` On Oct 13, 2007, at 5:21 AM, Shawn O. Pearce wrote: > Steffen Prohaska 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 >> >> can successfully resolve a 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 >> as someprefix/. >> >> 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 ```