{"thread":{"id":"10255","subject":"push fails with unexpected 'matches more than one'","startedAt":"2007-10-12T06:59:39Z","lastAt":"2007-10-13T16:51:58Z","messageCount":4,"participants":["Steffen Prohaska","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55528","messageId":"11921723791817-git-send-email-prohaska@zib.de","threadId":"10255","inReplyTo":null,"subject":"push fails with unexpected 'matches more than one'","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-12T06:59:39Z","receivedAt":"2007-10-12T06:59:39Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"This adds a test case for unambigous local match but multiple remote\nmatches. To me, it is unexpected that a ref that is perfectly defined\non the local side fails with 'matches more than one'.\n\nThe following rule could solve this:\nA ref shall first be unambigously resolved on the local side, and its\nfull name should be used for matching on the remote side.\nFor example 'frotz' resolves locally to 'heads/refs/frotz'.\nTherefore pretend the user had typed 'heads/refs/frotz'.\n\nBut maybe there is some hidden secret about the current rules that\nI do not see.\n\nSigned-off-by: Steffen Prohaska <prohaska@zib.de>\n---\n t/t5516-fetch-push.sh |    8 ++++++++\n 1 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex ca46aaf..f249216 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -244,4 +244,12 @@ test_expect_success 'push with colon-less refspec (4)' '\n \n '\n \n+test_expect_success 'push with colon-less refspec (locally unambigous)' '\n+\n+\tmk_test heads/frotz heads/t/frotz &&\n+\tgit branch -f frotz master &&\n+\tgit push testrepo frotz\n+\n+'\n+\n test_done\n-- \n1.5.3.4.219.gd0b2\n"},{"id":"55551","messageId":"91A04390-89B2-47B8-9B61-7C7E652670AE@zib.de","threadId":"10255","inReplyTo":"11921723791817-git-send-email-prohaska@zib.de","subject":"Re: push fails with unexpected 'matches more than one'","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-12T12:06:24Z","receivedAt":"2007-10-12T12:06:24Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 12, 2007, at 8:59 AM, Steffen Prohaska wrote:\n\n> This adds a test case for unambigous local match but multiple remote\n> matches. To me, it is unexpected that a ref that is perfectly defined\n> on the local side fails with 'matches more than one'.\n>\n> The following rule could solve this:\n> A ref shall first be unambigously resolved on the local side, and its\n> full name should be used for matching on the remote side.\n> For example 'frotz' resolves locally to 'heads/refs/frotz'.\n> Therefore pretend the user had typed 'heads/refs/frotz'.\n>\n> But maybe there is some hidden secret about the current rules that\n> I do not see.\n\nHere is a related question:\n\nI read carefully through the documentation of git-send-pack and\ngit-rev-parse. The current implementation of git-send-pack is in line\nwith the documented behaviour, as is the implementation of git-rev- \nparse.\n\nSo formally everything is correct.\n\nBut it is completely against my expectation that git-push <remote>  \n<head>\ncan successfully resolve a <head> that git-rev-parse fails to parse. I\nunderstand that refs are not revs ;). But nonetheless, I'd expect that a\nlocal ref that cannot be parsed by git-rev-parse should also fail to be\npushed by git-send-pack. I didn't expect that git-send-pack would locate\n<head> as someprefix/<head>.\n\nWhy is my expectation wrong?\nOr is the current specification of git-send-pack's ref parsing wrong?\n\n\tSteffen\n"},{"id":"55585","messageId":"20071013032100.GK27899@spearce.org","threadId":"10255","inReplyTo":"91A04390-89B2-47B8-9B61-7C7E652670AE@zib.de","subject":"Re: push fails with unexpected 'matches more than one'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-13T03:21:00Z","receivedAt":"2007-10-13T03:21:00Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Steffen Prohaska <prohaska@zib.de> wrote:\n> I read carefully through the documentation of git-send-pack and\n> git-rev-parse. The current implementation of git-send-pack is in line\n> with the documented behaviour, as is the implementation of git-rev- \n> parse.\n> \n> So formally everything is correct.\n> \n> But it is completely against my expectation that git-push <remote>  \n> <head>\n> can successfully resolve a <head> that git-rev-parse fails to parse. I\n> understand that refs are not revs ;). But nonetheless, I'd expect that a\n> local ref that cannot be parsed by git-rev-parse should also fail to be\n> pushed by git-send-pack. I didn't expect that git-send-pack would locate\n> <head> as someprefix/<head>.\n> \n> Why is my expectation wrong?\n> Or is the current specification of git-send-pack's ref parsing wrong?\n\nI think its a bug.  But I didn't write the original code.\n\nMeaning I think what happened here was someone wanted to enable\ngit-send-pack to match \"master\" here with \"refs/heads/master\" on\nthe remote side.  One easy way to do that was to see if any ref\nended with \"/master\", as that was what the ref here was called.\n\nWay back when that code was written most Git repositories probably\nonly ever had that one branch anyway, or maybe two (refs/heads/master\nand refs/heads/origin) so matching the trailing suffix never came\nup as a bug.  Nobody ever had two refs that could possibly match.\n\nThen the documentation got expanded to actually document the behavior\nthat git-send-pack implemented.  Unfortunately that codified the\nbug as documented behavior.\n\n\nSo I agree with you Steffen, this is a bug in send-pack, and I run\nup against it every once in a while.  I've specifically told my\ncoworkers \"NEVER, EVER, EVER, create a branch called 'master' that\nisn't exactly refs/heads/master OR ELSE I WILL COME BEAT YOU WITH A\nCLUE STICK\".  They still create \"refs/heads/experiments/master\".\n*sigh*.\n\nI think we should fix it.  Anyone that is relying on \"git push\n$url master\" to resolve to \"refs/heads/experimental/master\" on the\nremote side is already playing with fire.  But Junio is (rightfully\nso) very conservative and doesn't like to break a user's scripts.\nWe may not be able to fix this until Git 1.6.\n\n-- \nShawn.\n"},{"id":"55614","messageId":"CC1A592A-443B-4039-9FA4-2386066C22AD@zib.de","threadId":"10255","inReplyTo":"20071013032100.GK27899@spearce.org","subject":"Re: push fails with unexpected 'matches more than one'","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-13T16:51:58Z","receivedAt":"2007-10-13T16:51:58Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 13, 2007, at 5:21 AM, Shawn O. Pearce wrote:\n\n> Steffen Prohaska <prohaska@zib.de> wrote:\n>> I read carefully through the documentation of git-send-pack and\n>> git-rev-parse. The current implementation of git-send-pack is in line\n>> with the documented behaviour, as is the implementation of git-rev-\n>> parse.\n>>\n>> So formally everything is correct.\n>>\n>> But it is completely against my expectation that git-push <remote>\n>> <head>\n>> can successfully resolve a <head> that git-rev-parse fails to  \n>> parse. I\n>> understand that refs are not revs ;). But nonetheless, I'd expect  \n>> that a\n>> local ref that cannot be parsed by git-rev-parse should also fail  \n>> to be\n>> pushed by git-send-pack. I didn't expect that git-send-pack would  \n>> locate\n>> <head> as someprefix/<head>.\n>>\n>> Why is my expectation wrong?\n>> Or is the current specification of git-send-pack's ref parsing wrong?\n>\n> I think its a bug.  But I didn't write the original code.\n>\n> Meaning I think what happened here was someone wanted to enable\n> git-send-pack to match \"master\" here with \"refs/heads/master\" on\n> the remote side.  One easy way to do that was to see if any ref\n> ended with \"/master\", as that was what the ref here was called.\n>\n> Way back when that code was written most Git repositories probably\n> only ever had that one branch anyway, or maybe two (refs/heads/master\n> and refs/heads/origin) so matching the trailing suffix never came\n> up as a bug.  Nobody ever had two refs that could possibly match.\n>\n> Then the documentation got expanded to actually document the behavior\n> that git-send-pack implemented.  Unfortunately that codified the\n> bug as documented behavior.\n>\n>\n> So I agree with you Steffen, this is a bug in send-pack, and I run\n> up against it every once in a while.  I've specifically told my\n> coworkers \"NEVER, EVER, EVER, create a branch called 'master' that\n> isn't exactly refs/heads/master OR ELSE I WILL COME BEAT YOU WITH A\n> CLUE STICK\".  They still create \"refs/heads/experiments/master\".\n> *sigh*.\n>\n> I think we should fix it.  Anyone that is relying on \"git push\n> $url master\" to resolve to \"refs/heads/experimental/master\" on the\n> remote side is already playing with fire.  But Junio is (rightfully\n> so) very conservative and doesn't like to break a user's scripts.\n> We may not be able to fix this until Git 1.6.\n\nI'm working on this and will send patches tomorrow.\n\n\tSteffen\n"}]}