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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

To: Steffen Prohaska <prohaska@...>

Cc: Git Mailing List <git@...>

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

Date: Friday, October 12, 2007 - 11:21 pm

Steffen Prohaska <prohaska@zib.de> wrote:
quoted text> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:

push fails with unexpected 'matches more than one', Steffen Prohaska, (Fri Oct 12, 2:59 am)

Re: push fails with unexpected 'matches more than one', Steffen Prohaska, (Fri Oct 12, 8:06 am)

Re: push fails with unexpected 'matches more than one', Shawn O. Pearce, (Fri Oct 12, 11:21 pm)

Re: push fails with unexpected 'matches more than one', Steffen Prohaska, (Sat Oct 13, 12:51 pm)


linux-kernel:
Linus Torvalds	Re: LSM conversion to static interface
Ingo Molnar	[patch 03/13] syslets: generic kernel bits
Ingo Molnar	Re: [PATCH 6/6] sched: disabled rt-bandwidth by default
Greg Kroah-Hartman	[PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO
git:

linux-netdev:
David Miller	[GIT]: Networking
Gregory Haskins	[RFC PATCH 00/17] virtual-bus
Gerrit Renker	[PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side)
Jarek Poplawski	[PATCH] pkt_sched: Destroy gen estimators under rtnl_lock().
openbsd-misc:

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

Online users