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

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

[Joanna Wang]

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

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

[Jeff King]

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

> 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.

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".

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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".

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 ;-)

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

[Jeff King]

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

> Jeff King <peff@peff.net> writes:
> 
> > 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".
> 
> 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 ;-)

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

-Peff

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

[Junio C Hamano]

Joanna Wang <jojwang@google.com> writes:

> 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.

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.