All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Keith Derrick <keith.derrick@lge.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 0/5] interpret_branch_name bug potpourri
Date: Wed, 15 Jan 2014 13:03:35 -0800	[thread overview]
Message-ID: <xmqqsisp0xg8.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140115082528.GA18974@sigill.intra.peff.net> (Jeff King's message of "Wed, 15 Jan 2014 03:25:28 -0500")

Jeff King <peff@peff.net> writes:

> On Wed, Jan 15, 2014 at 12:00:03AM -0500, Jeff King wrote:
>
>>   $ git rev-parse --symbolic-full-name HEAD@{u}
>>   refs/remotes/origin/master
>>   $ git rev-parse --symbolic-full-name @mybranch@{u}
>>   @mybranch@{u}
>>   fatal: ambiguous argument '@mybranch@{u}': unknown revision or path
>>   not in the working tree.
>> 
>> So I do think there is a bug. The interpret_branch_name parser somehow
>> gets confused by the "@" in the name.
>
> The "somehow" is because we only look for the first "@", and never
> consider any possible marks after that. The series below fixes it, along
> with two other bugs I found while looking at this code. Ugh. Remind me
> never to look at our object name parser ever again.
>
> I feel pretty good that this is fixing real bugs and not regressing
> anything else. I would not be surprised if there are other weird things
> lurking, though. See the discussion in patch 4.
>
>   [1/5]: interpret_branch_name: factor out upstream handling
>   [2/5]: interpret_branch_name: rename "cp" variable to "at"
>   [3/5]: interpret_branch_name: always respect "namelen" parameter
>   [4/5]: interpret_branch_name: avoid @{upstream} past colon
>   [5/5]: interpret_branch_name: find all possible @-marks
>
> -Peff

All the steps looked very sensible.  Thanks for a pleasant read.

      parent reply	other threads:[~2014-01-15 21:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-14 23:04 BUG: check-ref-format and rev-parse can not handle branches with an @ in their name combined with @{u} Keith Derrick
2014-01-14 23:45 ` Junio C Hamano
2014-01-15  5:00   ` Jeff King
2014-01-15  7:46     ` Junio C Hamano
2014-01-15  7:47       ` Jeff King
2014-01-15  8:25     ` [PATCH 0/5] interpret_branch_name bug potpourri Jeff King
2014-01-15  8:26       ` [PATCH 1/5] interpret_branch_name: factor out upstream handling Jeff King
2014-01-15  8:27       ` [PATCH 2/5] interpret_branch_name: rename "cp" variable to "at" Jeff King
2014-01-15  8:31       ` [PATCH 3/5] interpret_branch_name: always respect "namelen" parameter Jeff King
2014-01-15  8:37       ` [PATCH 4/5] interpret_branch_name: avoid @{upstream} past colon Jeff King
2014-01-15  8:40       ` [PATCH 5/5] interpret_branch_name: find all possible @-marks Jeff King
2014-01-15 21:03       ` Junio C Hamano [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=xmqqsisp0xg8.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=keith.derrick@lge.com \
    --cc=peff@peff.net \
    /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.