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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]