* push fails with unexpected 'matches more than one'
@ 2007-10-12 6:59 Steffen Prohaska
2007-10-12 12:06 ` Steffen Prohaska
0 siblings, 1 reply; 4+ messages in thread
From: Steffen Prohaska @ 2007-10-12 6:59 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
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 <prohaska@zib.de>
---
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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: push fails with unexpected 'matches more than one'
2007-10-12 6:59 push fails with unexpected 'matches more than one' Steffen Prohaska
@ 2007-10-12 12:06 ` Steffen Prohaska
2007-10-13 3:21 ` Shawn O. Pearce
0 siblings, 1 reply; 4+ messages in thread
From: Steffen Prohaska @ 2007-10-12 12:06 UTC (permalink / raw)
To: Git Mailing List
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: push fails with unexpected 'matches more than one'
2007-10-12 12:06 ` Steffen Prohaska
@ 2007-10-13 3:21 ` Shawn O. Pearce
2007-10-13 16:51 ` Steffen Prohaska
0 siblings, 1 reply; 4+ messages in thread
From: Shawn O. Pearce @ 2007-10-13 3:21 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
Steffen Prohaska <prohaska@zib.de> 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 <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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: push fails with unexpected 'matches more than one'
2007-10-13 3:21 ` Shawn O. Pearce
@ 2007-10-13 16:51 ` Steffen Prohaska
0 siblings, 0 replies; 4+ messages in thread
From: Steffen Prohaska @ 2007-10-13 16:51 UTC (permalink / raw)
To: Git Mailing List; +Cc: Shawn O. Pearce
On Oct 13, 2007, at 5:21 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> 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 <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.
I'm working on this and will send patches tomorrow.
Steffen
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-10-13 16:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-12 6:59 push fails with unexpected 'matches more than one' Steffen Prohaska
2007-10-12 12:06 ` Steffen Prohaska
2007-10-13 3:21 ` Shawn O. Pearce
2007-10-13 16:51 ` Steffen Prohaska
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.