Bug: magic-less pathspecs that start with ":" not processed as expected.

What did you do before the bug happened? (Steps to reproduce your issue)

What did you expect to happen? (Expected behavior) `git stash push -- :file` where `:` is part of the filename, should search for files named ":file"

What happened instead? (Actual behavior) The match string used to find files is "file" without the ":".

What's different between what you expected and what actually happened? file named ":file" is not found.

Anything else you want to add: I believe this is due to parse_short_magic() not handling the case where ":" is part of the file name rather than a prefix for pathspec magic.

I could not find any documentation that says ":" is a reserved character to indicate pathspec magic symbols MUST follow or that ":file" is not a valid file name.

[System Info] git version 2.42.0 cpu: x86_64 no commit associated with this build shell-path: /bin/sh

[Enabled Hooks] not run from a git repository - no hooks to show

On Mon, Nov 06, 2023 at 10:54:03AM -0500, Joanna Wang wrote:

I think this is the correct behavior according to the documentation. From "git help glossary", the entry on "pathspec" says:

  A pathspec that begins with a colon : has special meaning. In the
  short form, the leading colon : is followed by zero or more "magic
  signature" letters (which optionally is terminated by another colon
  :), and the remainder is the pattern to match against the path.

So ":file" just has zero magic signature letters. I think you want:

  :::file

which of course is rather ugly, but then so is your filename. ;) Although longer, probably this is more readable:

  :(literal):file

And if you're working with a lot of such files (or you are scripting and know you have a set of filenames), then your best bet is probably turning on literal mode, like:

  git --literal-pathspecs ls-files -- :file

-Peff

PS It took me a while to figure out where we document pathspec syntax. I
   wonder if a "gitpathspecs" manpage would make sense, like we have
   "gitrevisions".

Jeff King <peff@peff.net> writes:

Yeah, I came to the same conclusion (should have saved time by scanning the mailing list before I started writing my response) and wondered where we wrote it down. The description you found in the glossary, as far as I recall, is the authoritative one and looks readable, but I agree it is not as discoverable as it should be.

A simpler and more readable workaround than ":::file" is "./:file" by the way ;-)

On Tue, Nov 07, 2023 at 08:29:34AM +0900, Junio C Hamano wrote:

Oh, indeed. That is much less horrible than ":(literal)". :)

-Peff

Joanna Wang <jojwang@google.com> writes:

Also, ":<path>" is a notation for the object name sitting at <path> in the index, so giving it from the command line is ambiguous, too. I thought that ./:<path> would be a common way to talk about such a path to git commands?

    $ date >./:now.txt
    $ git add ./:now.txt
    $ git rm ./:now.txt

I do not offhand remember where this is documented, but I agree that we need to make sure that we give help to users on things like this ("how do I add a file whose name begins with a dash" is another question I think we hear from time to time).

Thanks.