git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Joanna Wang <jojwang@google.com>
Cc: git@vger.kernel.org
Subject: Re: Bug: magic-less pathspecs that start with ":" not processed as expected.
Date: Mon, 6 Nov 2023 12:31:33 -0500	[thread overview]
Message-ID: <20231106173133.GC10414@coredump.intra.peff.net> (raw)
In-Reply-To: <CAMmZTi-JJ6=Uw_+r50hKMYf34D0NtqXhaA=f+11+wAQBjqA7_g@mail.gmail.com>

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

  reply	other threads:[~2023-11-06 17:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-06 15:54 Bug: magic-less pathspecs that start with ":" not processed as expected Joanna Wang
2023-11-06 17:31 ` Jeff King [this message]
2023-11-06 23:29   ` Junio C Hamano
2023-11-07  3:25     ` Jeff King
2023-11-06 23:25 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231106173133.GC10414@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jojwang@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).