Re: [BUG] "git --literal-pathspecs blame" broken in master

From: Jeff King <peff@peff.net>
Date: Oct 25, 2013, 04:18 UTC
Message-ID: <20131025041837.GA17266@sigill.intra.peff.net>
In-Reply-To: <CACsJy8Aw9KyeWqgC5KQmqPrzD7J4Gga1ibDTvfNQFaVN303U9g@mail.gmail.com>

On Fri, Oct 25, 2013 at 11:16:08AM +0700, Nguyen Thai Ngoc Duy wrote:

Show 16 quoted lines

> > All of the GUARD_PATHSPEC calls indicate that everybody understands
> > PATHSPEC_LITERAL. It is not technically true that git-blame understands
> > the literal pathspec magic:
> >
> >   $ git blame -- ':(literal)revision.c'
> >   fatal: no such path ':(literal)revision.c' in HEAD
> >
> > but that is a separate bug (that blame considers the argument as a path
> > first before feeding it to the pathspec machinery). The patch above does
> > not fix that, but AFAICT it does not make anything worse.
> 
> I did consider this change but dropped it because there are more
> parse_pathspec() calls with PATHSPEC_ALL_MAGIC as mask. Thanks for
> bringing up ":(literal)".  I guess we need to change prefix_pathspec()
> to set PATHSPEC_LITERAL only when :(literal) is present, not when
> --literal-pathspecs is used.

I considered suggesting that, too, but it means that everywhere that checks for PATHSPEC_LITERAL must _also_ check for literal_global (e.g., if they were deciding to feed the result to fnmatch). Whereas if we catch it at the parse_pathspec layer, then the consumers of the pathspec just need to check the one flag.

I dunno. I haven't kept up very well with your work in this area, so you probably have a better sense than I do of what would be the most elegant.

-Peff