From: Adam Johnson <me@adamj.eu>
Date: Sun, 12 Mar 2023 11:52:54 GMT
Subject: Re: [PATCH] ls-files: document that pathspecs are supported
Message-ID: <CAMyDDM3VyCdwOLhay0PC8G6azoWCFpxoB1K76mvo5nd2C+sfCg@mail.gmail.com>
In-Reply-To: <xmqqzg8jxc2r.fsf@gitster.g>

Thank you Junio, that's very good review feedback. Thank you for
finding the correct past commit. I am submitting an updated patch now.


On Sat, Mar 11, 2023 at 8:33 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Adam Johnson via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Adam Johnson <me@adamj.eu>
> >
> > The command has taken pathspecs, not just filenames, since f0096c06bcd
> > (Convert read_tree{,_recursive} to support struct pathspec, 2011-03-25).
>
> Isn't that commit about ls-tree?  The commit does change how the
> tree overlay (i.e. the --with-tree=<tree-ish> option) interacts with
> the given pathspec arguments but that is only because that commit
> changes how read_tree_recursive() has to be called.  The support of
> pathspec matching in ls-files dates back to 56fc5108 ([PATCH]
> git-ls-files: generalized pathspecs, 2005-08-21), arguably even
> before the commit "generalized" the already existing path pattern
> match feature.
>
> > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > index 1abdd3c21c5..2f62374062c 100644
> > --- a/Documentation/git-ls-files.txt
> > +++ b/Documentation/git-ls-files.txt
> > @@ -21,7 +21,7 @@ SYNOPSIS
> >               [--exclude-standard]
> >               [--error-unmatch] [--with-tree=<tree-ish>]
> >               [--full-name] [--recurse-submodules]
> > -             [--abbrev[=<n>]] [--format=<format>] [--] [<file>...]
> > +             [--abbrev[=<n>]] [--format=<format>] [--] [<pathspec>...]
>
> Good.
>
> >  DESCRIPTION
> >  -----------
> > @@ -127,12 +127,12 @@ OPTIONS
> >       in each directory, and the user's global exclusion file.
> >
> >  --error-unmatch::
> > -     If any <file> does not appear in the index, treat this as an
> > +     If any <pathspec> does not appear in the index, treat this as an
> >       error (return 1).
>
> This is no longer correct.  "If no path that matches <pathspec>
> appears in the index".  When we are given <pathspec>, say '*.txt',
> a path whose string is literally '*.txt' may not appear in the index,
> but as long as there is a path that matches the pattern exists,
> this option does not lead to an error.
>
> > -<file>::
> > +<pathspec>::
> >       Files to show. If no files are given all files which match the other
>
> The description also needs to be updated.  "Limits the files to show
> to only those that match the given pathspec" or something along that
> line.
>
> Thanks.