git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Adam Johnson via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Elijah Newren <newren@gmail.com>,
	Adam Johnson <me@adamj.eu>
Subject: Re: [PATCH] ls-files: document that pathspecs are supported
Date: Sat, 11 Mar 2023 12:33:32 -0800	[thread overview]
Message-ID: <xmqqzg8jxc2r.fsf@gitster.g> (raw)
In-Reply-To: <pull.1466.git.git.1678526355280.gitgitgadget@gmail.com> (Adam Johnson via GitGitGadget's message of "Sat, 11 Mar 2023 09:19:15 +0000")

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

  reply	other threads:[~2023-03-11 20:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-11  9:19 [PATCH] ls-files: document that pathspecs are supported Adam Johnson via GitGitGadget
2023-03-11 20:33 ` Junio C Hamano [this message]
2023-03-12 11:52   ` Adam Johnson
2023-03-12 11:55 ` [PATCH v2] " Adam Johnson via GitGitGadget

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=xmqqzg8jxc2r.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=me@adamj.eu \
    --cc=newren@gmail.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).