[BUG] "git --literal-pathspecs blame" broken in master
- From
Jeff King <peff@peff.net>
- Date
- Oct 25, 2013, 03:49 UTC
- Message-ID
- <20131025034947.GA4959@sigill.intra.peff.net>
There seems to be a bad interaction with --literal-pathspecs and the pathspec magic that is in master. Here's an example:
[setup] $ git init $ echo content >':(foo)bar' $ git add . && git commit -m foo
[with git v1.8.4] $ git blame ':(foo)bar' ^6b07eb4 (Jeff King 2013-10-24 22:59:02 -0400 1) content $ git --literal-pathspecs blame ':(foo)bar' ^6b07eb4 (Jeff King 2013-10-24 22:59:02 -0400 1) content
So originally "blame" did not handle pathspec magic at all, and --literal-pathspecs did nothing. So the former is arguably buggy, but the latter did the right thing (if only by accident :) ).
Then along came 9a08727 (remove init_pathspec() in favor of parse_pathspec(), 2013-07-14), and we get:
$ git blame ':(foo)bar' fatal: Invalid pathspec magic 'foo' in ':(foo)bar' $ git --literal-pathspecs blame ':(foo)bar' fatal: Invalid pathspec magic 'foo' in ':(foo)bar'
The first is an improvement, because we are now consistent with other pathspec handling in git. But the latter is a regression; we are not respecting the literal pathspec flag.
We get another change with a16bf9d (pathspec: make --literal-pathspecs disable pathspec magic, 2013-07-14), which I would think would fix things, but doesn't.
$ git blame ':(foo)bar' fatal: Invalid pathspec magic 'foo' in ':(foo)bar' $ git --literal-pathspecs blame ':(foo)bar' fatal: :(foo)bar: pathspec magic not supported by this command: 'literal'
The first one remains good, but the second one is still broken. I haven't dug further yet, but I thought it might be a bit more obvious to you.
-Peff