All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Prohaska <prohaska@zib.de>
To: Git Mailing List <git@vger.kernel.org>
Cc: "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: push fails with unexpected 'matches more than one'
Date: Sat, 13 Oct 2007 18:51:58 +0200	[thread overview]
Message-ID: <CC1A592A-443B-4039-9FA4-2386066C22AD@zib.de> (raw)
In-Reply-To: <20071013032100.GK27899@spearce.org>


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

      reply	other threads:[~2007-10-13 16:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CC1A592A-443B-4039-9FA4-2386066C22AD@zib.de \
    --to=prohaska@zib.de \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.