From: Jeff King <peff@peff.net>
Date: Tue, 11 Oct 2011 23:07:49 GMT
Subject: Re: Re* [PATCH v3 19/22] resolve_ref(): emit warnings for improperly-formatted references
Message-ID: <20111011230749.GA29785@sigill.intra.peff.net>
In-Reply-To: <7v39ezffq5.fsf_-_@alter.siamese.dyndns.org>

On Tue, Oct 11, 2011 at 01:14:26PM -0700, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> >> I think we've discussed tightening it a few years ago already.
> >>
> >> HEAD, MERGE_HEAD, FETCH_HEAD, etc. all are "^[_A-Z]*$" and it may even be
> >> a good idea to insist "^[_A-Z]*HEAD$" or even "^([A-Z][A-Z]*_)?HEAD$".
> >
> > Perhaps like this? Only compile tested...
> 
> Not quite. There are at least three bugs in the patch.
> 
>  - Some subsystems use random refnames like NOTES_MERGE_PARTIAL that would
>    not match "^([A-Z][A-Z]*_)?HEAD$". The rule needs to be relaxed;
> 
>  - dwim_ref() can be fed "refs/heads/master" and is expected to dwim it to
>    the master branch.
> 
>  - These codepaths get pointer+length so that it can be told to parse only
>    the first 4 bytes in "HEAD:$path".

One more bug. :)

We also look at ref_rev_parse_rules in shorten_unambiguous_ref. So even
with your patch, I still get the warning with:

  $ git branch config
  $ git for-each-ref --format='%(refname:short)' refs/heads/

It looks like we also use it in remote.c:count_refspec_match, but I
haven't figured out if that can trigger a warning or not.

-Peff