threads / patch / 59081

patch, 4 partsls-files: clarify descriptions of file selection options

Subject: [PATCH 2/4] ls-files: clarify descriptions of file selection options

## tl;dr

12 messages between Jan 13, 2023 and Jan 16, 2023. Diffs are folded; open one to read it.

replies: 11people: 2as markdown or json

Elijah Newren via GitGitGadget· Jan 13, 2023, 04:41 UTC · lore

[PATCH 0/4] clarify ls-files docs

"git ls-files -t" was marked as semi-deprecated back in 5bc0e247c4 ("Document ls-files -t as semi-obsolete.", 2010-07-28); quoting that commit message:

    git ls-files -t" is [...] badly documented, hence we point the
    users to superior alternatives.
    The feature is marked as "semi-obsolete" but not "scheduled for removal"
    since it's a plumbing command, scripts might use it, and Git testsuite
    already uses it to test the state of the index.

Looking over the manual, "git ls-files -t" is very easy to misunderstand...as are several things besides the "-t" option within that manual page. I recall a number of discussions over the years on the mailing list about various confusing aspects of ls-files, and I think a number of those misunderstandings could have been avoided with a few small clarifications. This series sets about to do that, as well as remove the "semi-deprecated" notice on git ls-files -t. That particular command is rather integral to sparse-checkout usage (and doesn't seem to confuse in that case), and I think the improvements avoid the original problems. However, I have kept the comments about git status --porcelain and such being likely better candidates for a number of things that git ls-files -t might have historically been used for.

Series spurred by https://lore.kernel.org/git/CABPp-BGsD=6PiJtnsuYPsiZJ1rm2X8yTeu-YeP4q5uu5UDw2og@mail.gmail.com/

Elijah Newren (4):
  ls-files: add missing documentation for --resolve-undo option
  ls-files: clarify descriptions of file selection options
  ls-files: clarify descriptions of status tags for -t
  ls-files: guide folks to --exclude-standard over other --exclude*
    options
 Documentation/git-ls-files.txt | 79 ++++++++++++++++++++++------------
 1 file changed, 52 insertions(+), 27 deletions(-)
base-commit: 2b4f5a4e4bb102ac8d967cea653ed753b608193c
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1463%2Fnewren%2Fls-files-docs-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1463/newren/ls-files-docs-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1463
-- 
gitgitgadget
Elijah Newren via GitGitGadget· Jan 13, 2023, 04:41 UTC · re: Elijah Newren via GitGitGadget · lore
From: Elijah Newren <newren@gmail.com>

The previous descriptions of the file selection options were very easy to misunderstand. For example:

  * "Show cached files in the output"
    This could be interpreted as meaning "show files which have been
    modified and git-add'ed, i.e. files which have cached changes
    relative to HEAD".
  * "Show deleted files"
    This could be interpreted as meaning "for each `git rm $FILE` we
    ran, show me $FILE"
  * "Show modified files"
    This could be interpreted as meaning "show files which have been
    modified and git-add'ed" or as "show me files that differ from HEAD"
    or as "show me undeleted files different from HEAD" (given that
    --deleted is a separate option), none of which are correct.

Further, it's not very clear when some options only modify and/or override other options, as was the case with --ignored, --directory, and --unmerged (I've seen folks confused by each of them on the mailing list, sometimes even fellow git developers.)

Tweak these definitions, and the one for --killed, to try to make them all a bit more clear. Finally, also clarify early on that duplicate reports for paths are often expected (both when (a) there are multiple entries for the file in the index -- i.e. when there are conflicts, and also (b) when the user specifies options that might pick the same file multiple times, such as `git ls-files --cached --deleted --modified` when there is a file with an unstaged deletion).

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 Documentation/git-ls-files.txt | 37 ++++++++++++++++++++++------------
 1 file changed, 24 insertions(+), 13 deletions(-)
Show changes to Documentation/git-ls-files.txt +24 −13
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index cb071583f8b..f89ab1bfc98 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -29,21 +29,26 @@ This merges the file listing in the index with the actual working
 directory list, and shows different combinations of the two.
 
 One or more of the options below may be used to determine the files
-shown:
+shown, and each file may be printed multiple times if there are
+multiple entries in the index or multiple statuses are applicable for
+the relevant file selection options.
 
 OPTIONS
 -------
 -c::
 --cached::
-	Show cached files in the output (default)
+	Show all files cached in Git's index, i.e. all tracked files.
+	(This is the default if no -c/-s/-d/-o/-u/-k/-m/--resolve-undo
+	options are specified.)
 
 -d::
 --deleted::
-	Show deleted files in the output
+	Show files with an unstaged deletion
 
 -m::
 --modified::
-	Show modified files in the output
+	Show files with an unstaged modification (note that an unstaged
+	deletion also counts as an unstaged modification)
 
 -o::
 --others::
@@ -51,11 +56,14 @@ OPTIONS
 
 -i::
 --ignored::
-	Show only ignored files in the output. When showing files in the
-	index, print only those matched by an exclude pattern. When
-	showing "other" files, show only those matched by an exclude
-	pattern. Standard ignore rules are not automatically activated,
-	therefore at least one of the `--exclude*` options is required.
+	Show only ignored files in the output.  Must be used with
+	either an explicit '-c' or '-o'.  When showing files in the
+	index (i.e. when used with '-c'), print only those files
+	matching an exclude pattern.  When showing "other" files
+	(i.e. when used with '-o'), show only those matched by an
+	exclude pattern.  Standard ignore rules are not automatically
+	activated, therefore at least one of the `--exclude*` options
+	is required.
 
 -s::
 --stage::
@@ -64,19 +72,22 @@ OPTIONS
 --directory::
 	If a whole directory is classified as "other", show just its
 	name (with a trailing slash) and not its whole contents.
+	Has no effect without -o/--others.
 
 --no-empty-directory::
 	Do not list empty directories. Has no effect without --directory.
 
 -u::
 --unmerged::
-	Show unmerged files in the output (forces --stage)
+	Show information about unmerged files in the output, but do
+	not show any other tracked files (forces --stage, overrides
+	--cached).
 
 -k::
 --killed::
-	Show files on the filesystem that need to be removed due
-	to file/directory conflicts for checkout-index to
-	succeed.
+	Show untracked files on the filesystem that need to be removed
+	due to file/directory conflicts for tracked files to be able to
+	be written to the filesystem.
 
 --resolve-undo::
 	Show files having resolve-undo information in the index
-- 
gitgitgadget
ZheNing Hu· Jan 14, 2023, 08:21 UTC · re: Elijah Newren via GitGitGadget · lore

Re: [PATCH 2/4] ls-files: clarify descriptions of file selection options

Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> 于2023年1月13日周五 12:41写道:
Show 52 quoted lines
>
> From: Elijah Newren <newren@gmail.com>
>
> The previous descriptions of the file selection options were very easy
> to misunderstand.  For example:
>
>   * "Show cached files in the output"
>     This could be interpreted as meaning "show files which have been
>     modified and git-add'ed, i.e. files which have cached changes
>     relative to HEAD".
>
>   * "Show deleted files"
>     This could be interpreted as meaning "for each `git rm $FILE` we
>     ran, show me $FILE"
>
>   * "Show modified files"
>     This could be interpreted as meaning "show files which have been
>     modified and git-add'ed" or as "show me files that differ from HEAD"
>     or as "show me undeleted files different from HEAD" (given that
>     --deleted is a separate option), none of which are correct.
>
> Further, it's not very clear when some options only modify and/or
> override other options, as was the case with --ignored, --directory, and
> --unmerged (I've seen folks confused by each of them on the mailing
> list, sometimes even fellow git developers.)
>
> Tweak these definitions, and the one for --killed, to try to make them
> all a bit more clear.  Finally, also clarify early on that duplicate
> reports for paths are often expected (both when (a) there are multiple
> entries for the file in the index -- i.e. when there are conflicts, and
> also (b) when the user specifies options that might pick the same file
> multiple times, such as `git ls-files --cached --deleted --modified`
> when there is a file with an unstaged deletion).
>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  Documentation/git-ls-files.txt | 37 ++++++++++++++++++++++------------
>  1 file changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> index cb071583f8b..f89ab1bfc98 100644
> --- a/Documentation/git-ls-files.txt
> +++ b/Documentation/git-ls-files.txt
> @@ -29,21 +29,26 @@ This merges the file listing in the index with the actual working
>  directory list, and shows different combinations of the two.
>
>  One or more of the options below may be used to determine the files
> -shown:
> +shown, and each file may be printed multiple times if there are
> +multiple entries in the index or multiple statuses are applicable for
> +the relevant file selection options.
>
`--deduplicate` option can be used to remove deduped output.
Show 14 quoted lines
>  OPTIONS
>  -------
>  -c::
>  --cached::
> -       Show cached files in the output (default)
> +       Show all files cached in Git's index, i.e. all tracked files.
> +       (This is the default if no -c/-s/-d/-o/-u/-k/-m/--resolve-undo
> +       options are specified.)
>
>  -d::
>  --deleted::
> -       Show deleted files in the output
> +       Show files with an unstaged deletion
>

This is a nice fix: make it clear to the user that only files in the working tree are deleted, not in the index.

Show 6 quoted lines
>  -m::
>  --modified::
> -       Show modified files in the output
> +       Show files with an unstaged modification (note that an unstaged
> +       deletion also counts as an unstaged modification)
>

Good to mention that deleted files are also modified, otherwise no one looking at the documentation would know that.

Show 52 quoted lines
>  -o::
>  --others::
> @@ -51,11 +56,14 @@ OPTIONS
>
>  -i::
>  --ignored::
> -       Show only ignored files in the output. When showing files in the
> -       index, print only those matched by an exclude pattern. When
> -       showing "other" files, show only those matched by an exclude
> -       pattern. Standard ignore rules are not automatically activated,
> -       therefore at least one of the `--exclude*` options is required.
> +       Show only ignored files in the output.  Must be used with
> +       either an explicit '-c' or '-o'.  When showing files in the
> +       index (i.e. when used with '-c'), print only those files
> +       matching an exclude pattern.  When showing "other" files
> +       (i.e. when used with '-o'), show only those matched by an
> +       exclude pattern.  Standard ignore rules are not automatically
> +       activated, therefore at least one of the `--exclude*` options
> +       is required.
>
>  -s::
>  --stage::
> @@ -64,19 +72,22 @@ OPTIONS
>  --directory::
>         If a whole directory is classified as "other", show just its
>         name (with a trailing slash) and not its whole contents.
> +       Has no effect without -o/--others.
>
>  --no-empty-directory::
>         Do not list empty directories. Has no effect without --directory.
>
>  -u::
>  --unmerged::
> -       Show unmerged files in the output (forces --stage)
> +       Show information about unmerged files in the output, but do
> +       not show any other tracked files (forces --stage, overrides
> +       --cached).
>
>  -k::
>  --killed::
> -       Show files on the filesystem that need to be removed due
> -       to file/directory conflicts for checkout-index to
> -       succeed.
> +       Show untracked files on the filesystem that need to be removed
> +       due to file/directory conflicts for tracked files to be able to
> +       be written to the filesystem.
>
>  --resolve-undo::
>         Show files having resolve-undo information in the index
> --
> gitgitgadget
>
Elijah Newren· Jan 14, 2023, 19:42 UTC · re: ZheNing Hu · lore

Re: [PATCH 2/4] ls-files: clarify descriptions of file selection options

On Sat, Jan 14, 2023 at 12:21 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> 于2023年1月13日周五 12:41写道:
[...]
Show 15 quoted lines
> > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > index cb071583f8b..f89ab1bfc98 100644
> > --- a/Documentation/git-ls-files.txt
> > +++ b/Documentation/git-ls-files.txt
> > @@ -29,21 +29,26 @@ This merges the file listing in the index with the actual working
> >  directory list, and shows different combinations of the two.
> >
> >  One or more of the options below may be used to determine the files
> > -shown:
> > +shown, and each file may be printed multiple times if there are
> > +multiple entries in the index or multiple statuses are applicable for
> > +the relevant file selection options.
> >
>
> `--deduplicate` option can be used to remove deduped output.
Yes, I'm aware.

If you're suggesting adding this text at this point in the document, it occurred to me already, but I chose not to put it here. The reason is that this is a brief synopsis. The "relevant file selection options" of this brief synopsis could also be expanded to mention what they are or what the default selection is or whatever. But folks can read on to learn that `deduplicate` can be used to remove duplicate options. Likewise, anyone who reads the text about "relevant file selections" and wants to learn more is inclined to read on to the other options to find out.

In contrast, no one will be motivated to read on to find out that files can be printed multiple times if we don't mention it right here. And they are likely to get confused when it happens, thinking it is a bug (in fact, I can point out emails from the archives where that has happened). Without mentioning the possibility of multiple files at this point, we have a discoverability problem.

There is no similar discoverability and negative-surprise problem I can think of by omitting other details, so there is no need to expand this brief synopsis any further.

The one place we could potentially change thing that might help, is moving the text about -c being the default from under the -c option and putting it here. That's a toss-up to me, but for now I elected to keep it where it is.

Show 30 quoted lines
> >  OPTIONS
> >  -------
> >  -c::
> >  --cached::
> > -       Show cached files in the output (default)
> > +       Show all files cached in Git's index, i.e. all tracked files.
> > +       (This is the default if no -c/-s/-d/-o/-u/-k/-m/--resolve-undo
> > +       options are specified.)
> >
> >  -d::
> >  --deleted::
> > -       Show deleted files in the output
> > +       Show files with an unstaged deletion
> >
>
> This is a nice fix: make it clear to the user that only files in the
> working tree are deleted, not in the index.
>
> >  -m::
> >  --modified::
> > -       Show modified files in the output
> > +       Show files with an unstaged modification (note that an unstaged
> > +       deletion also counts as an unstaged modification)
> >
>
> Good to mention that deleted files are also modified, otherwise no one
> looking at the documentation would know that.
>
> >  -o::
> >  --others::
[...]
Thanks for taking a look!
ZheNing Hu· Jan 16, 2023, 17:12 UTC · re: Elijah Newren · lore

Re: [PATCH 2/4] ls-files: clarify descriptions of file selection options

Elijah Newren <newren@gmail.com> 于2023年1月15日周日 03:42写道:
Show 44 quoted lines
>
> On Sat, Jan 14, 2023 at 12:21 AM ZheNing Hu <adlternative@gmail.com> wrote:
> >
> > Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> 于2023年1月13日周五 12:41写道:
> [...]
> > > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > > index cb071583f8b..f89ab1bfc98 100644
> > > --- a/Documentation/git-ls-files.txt
> > > +++ b/Documentation/git-ls-files.txt
> > > @@ -29,21 +29,26 @@ This merges the file listing in the index with the actual working
> > >  directory list, and shows different combinations of the two.
> > >
> > >  One or more of the options below may be used to determine the files
> > > -shown:
> > > +shown, and each file may be printed multiple times if there are
> > > +multiple entries in the index or multiple statuses are applicable for
> > > +the relevant file selection options.
> > >
> >
> > `--deduplicate` option can be used to remove deduped output.
>
> Yes, I'm aware.
>
> If you're suggesting adding this text at this point in the document,
> it occurred to me already, but I chose not to put it here.  The reason
> is that this is a brief synopsis.  The "relevant file selection
> options" of this brief synopsis could also be expanded to mention what
> they are or what the default selection is or whatever.  But folks can
> read on to learn that `deduplicate` can be used to remove duplicate
> options.  Likewise, anyone who reads the text about "relevant file
> selections" and wants to learn more is inclined to read on to the
> other options to find out.
>
> In contrast, no one will be motivated to read on to find out that
> files can be printed multiple times if we don't mention it right here.
> And they are likely to get confused when it happens, thinking it is a
> bug (in fact, I can point out emails from the archives where that has
> happened).  Without mentioning the possibility of multiple files at
> this point, we have a discoverability problem.
>
> There is no similar discoverability and negative-surprise problem I
> can think of by omitting other details, so there is no need to expand
> this brief synopsis any further.
>

Well, you are right. It may be better to be concise here, telling users too much will make it difficult to read.

Show 5 quoted lines
> The one place we could potentially change thing that might help, is
> moving the text about -c being the default from under the -c option
> and putting it here.  That's a toss-up to me, but for now I elected to
> keep it where it is.
>
I think it's fine to do this or not.
Show 33 quoted lines
> > >  OPTIONS
> > >  -------
> > >  -c::
> > >  --cached::
> > > -       Show cached files in the output (default)
> > > +       Show all files cached in Git's index, i.e. all tracked files.
> > > +       (This is the default if no -c/-s/-d/-o/-u/-k/-m/--resolve-undo
> > > +       options are specified.)
> > >
> > >  -d::
> > >  --deleted::
> > > -       Show deleted files in the output
> > > +       Show files with an unstaged deletion
> > >
> >
> > This is a nice fix: make it clear to the user that only files in the
> > working tree are deleted, not in the index.
> >
> > >  -m::
> > >  --modified::
> > > -       Show modified files in the output
> > > +       Show files with an unstaged modification (note that an unstaged
> > > +       deletion also counts as an unstaged modification)
> > >
> >
> > Good to mention that deleted files are also modified, otherwise no one
> > looking at the documentation would know that.
> >
> > >  -o::
> > >  --others::
> [...]
>
> Thanks for taking a look!
Elijah Newren via GitGitGadget· Jan 13, 2023, 04:41 UTC · re: Elijah Newren via GitGitGadget · lore

[PATCH 1/4] ls-files: add missing documentation for --resolve-undo option

From: Elijah Newren <newren@gmail.com>

ls-files' --resolve-undo option has existed ever since 9d9a2f4aba ("resolve-undo: basic tests", 2009-12-25), but was never documented. However, the option has been referred to in the ls-files manual itself ever since ce74de931d ("ls-files: introduce "--format" option", 2022-07-23), making its omission a bit jarring. Document this option.

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 Documentation/git-ls-files.txt | 9 +++++++++
 1 file changed, 9 insertions(+)
Show changes to Documentation/git-ls-files.txt +9 −0
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 440043cdb8e..cb071583f8b 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -12,6 +12,7 @@ SYNOPSIS
 'git ls-files' [-z] [-t] [-v] [-f]
 		[-c|--cached] [-d|--deleted] [-o|--others] [-i|--ignored]
 		[-s|--stage] [-u|--unmerged] [-k|--killed] [-m|--modified]
+		[--resolve-undo]
 		[--directory [--no-empty-directory]] [--eol]
 		[--deduplicate]
 		[-x <pattern>|--exclude=<pattern>]
@@ -77,6 +78,13 @@ OPTIONS
 	to file/directory conflicts for checkout-index to
 	succeed.
 
+--resolve-undo::
+	Show files having resolve-undo information in the index
+	together with their resolve-undo information.  (resolve-undo
+	information is what is used to implement "git checkout -m
+	$PATH", i.e. to recreate merge conflicts that were
+	accidentally resolved)
+
 -z::
 	\0 line termination on output and do not quote filenames.
 	See OUTPUT below for more information.
@@ -136,6 +144,7 @@ a space) at the start of each line:
 	C::	modified/changed
 	K::	to be killed
 	?::	other
+	U::     resolve-undo
 --
 
 -v::
-- 
gitgitgadget
ZheNing Hu· Jan 14, 2023, 08:07 UTC · re: Elijah Newren via GitGitGadget · lore

Re: [PATCH 1/4] ls-files: add missing documentation for --resolve-undo option

Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> 于2023年1月13日周五 12:41写道:
Show 9 quoted lines
>
> From: Elijah Newren <newren@gmail.com>
>
> ls-files' --resolve-undo option has existed ever since 9d9a2f4aba
> ("resolve-undo: basic tests", 2009-12-25), but was never documented.
> However, the option has been referred to in the ls-files manual itself
> ever since ce74de931d ("ls-files: introduce "--format" option",
> 2022-07-23), making its omission a bit jarring.  Document this option.
>

I checked this should be the only option that git ls-files forgot to document, thanks.

Show 42 quoted lines
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  Documentation/git-ls-files.txt | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> index 440043cdb8e..cb071583f8b 100644
> --- a/Documentation/git-ls-files.txt
> +++ b/Documentation/git-ls-files.txt
> @@ -12,6 +12,7 @@ SYNOPSIS
>  'git ls-files' [-z] [-t] [-v] [-f]
>                 [-c|--cached] [-d|--deleted] [-o|--others] [-i|--ignored]
>                 [-s|--stage] [-u|--unmerged] [-k|--killed] [-m|--modified]
> +               [--resolve-undo]
>                 [--directory [--no-empty-directory]] [--eol]
>                 [--deduplicate]
>                 [-x <pattern>|--exclude=<pattern>]
> @@ -77,6 +78,13 @@ OPTIONS
>         to file/directory conflicts for checkout-index to
>         succeed.
>
> +--resolve-undo::
> +       Show files having resolve-undo information in the index
> +       together with their resolve-undo information.  (resolve-undo
> +       information is what is used to implement "git checkout -m
> +       $PATH", i.e. to recreate merge conflicts that were
> +       accidentally resolved)
> +
>  -z::
>         \0 line termination on output and do not quote filenames.
>         See OUTPUT below for more information.
> @@ -136,6 +144,7 @@ a space) at the start of each line:
>         C::     modified/changed
>         K::     to be killed
>         ?::     other
> +       U::     resolve-undo
>  --
>
>  -v::
> --
> gitgitgadget
>
Elijah Newren via GitGitGadget· Jan 13, 2023, 04:41 UTC · re: Elijah Newren via GitGitGadget · lore

[PATCH 3/4] ls-files: clarify descriptions of status tags for -t

From: Elijah Newren <newren@gmail.com>

Much like the file selection options we tweaked in the last commit, the status tags printed with -t had descriptions that were easy to misunderstand, and for many of the same reasons. Clarify them.

Also, while at it, remove the "semi-deprecated" comment for "git ls-files -t". The -t option was marked as semi-deprecated in 5bc0e247c4 ("Document ls-files -t as semi-obsolete.", 2010-07-28) because:

    "git ls-files -t" is [...] badly documented, hence we point the
    users to superior alternatives.
    The feature is marked as "semi-obsolete" but not "scheduled for removal"
    since it's a plumbing command, scripts might use it, and Git testsuite
    already uses it to test the state of the index.

Marking it as obsolete because it was easily misunderstood, which I think was primarily due to documentation problems, is one strategy, but I think fixing the documentation is a better option. Especially since in the intervening time, "git ls-files -t" has become heavily used by sparse-checkout users where the same confusion just doesn't apply.

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 Documentation/git-ls-files.txt | 28 +++++++++++++++-------------
 1 file changed, 15 insertions(+), 13 deletions(-)
Show changes to Documentation/git-ls-files.txt +15 −13
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index f89ab1bfc98..3886d58d178 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -137,25 +137,27 @@ OPTIONS
 	with `-s` or `-u` options does not make any sense.
 
 -t::
-	This feature is semi-deprecated. For scripting purpose,
-	linkgit:git-status[1] `--porcelain` and
+	Show status tags together with filenames.  Note that for
+	scripting purposes, linkgit:git-status[1] `--porcelain` and
 	linkgit:git-diff-files[1] `--name-status` are almost always
 	superior alternatives, and users should look at
 	linkgit:git-status[1] `--short` or linkgit:git-diff[1]
 	`--name-status` for more user-friendly alternatives.
 +
 --
-This option identifies the file status with the following tags (followed by
-a space) at the start of each line:
-
-	H::	cached
-	S::	skip-worktree
-	M::	unmerged
-	R::	removed/deleted
-	C::	modified/changed
-	K::	to be killed
-	?::	other
-	U::     resolve-undo
+This option provides a reason for showing each filename, in the form
+of a status tag (which is followed by a space and then the filename).
+The status tags are all single characters from the following list:
+
+	H::	tracked file that is not either unmerged or skip-worktree
+	S::	tracked file that is skip-worktree
+	M::	tracked file that is unmerged
+	R::	tracked file with unstaged removal/deletion
+	C::	tracked file with unstaged modification/change
+	K::	untracked paths which are part of file/directory conflicts
+		which prevent checking out tracked files
+	?::	untracked file
+	U::     file with resolve-undo information
 --
 
 -v::
-- 
gitgitgadget
ZheNing Hu· Jan 14, 2023, 08:26 UTC · re: Elijah Newren via GitGitGadget · lore

Re: [PATCH 3/4] ls-files: clarify descriptions of status tags for -t

Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> 于2023年1月13日周五 12:41写道:
Show 72 quoted lines
>
> From: Elijah Newren <newren@gmail.com>
>
> Much like the file selection options we tweaked in the last commit, the
> status tags printed with -t had descriptions that were easy to
> misunderstand, and for many of the same reasons.  Clarify them.
>
> Also, while at it, remove the "semi-deprecated" comment for "git
> ls-files -t".  The -t option was marked as semi-deprecated in 5bc0e247c4
> ("Document ls-files -t as semi-obsolete.", 2010-07-28) because:
>
>     "git ls-files -t" is [...] badly documented, hence we point the
>     users to superior alternatives.
>     The feature is marked as "semi-obsolete" but not "scheduled for removal"
>     since it's a plumbing command, scripts might use it, and Git testsuite
>     already uses it to test the state of the index.
>
> Marking it as obsolete because it was easily misunderstood, which I
> think was primarily due to documentation problems, is one strategy, but
> I think fixing the documentation is a better option.  Especially since
> in the intervening time, "git ls-files -t" has become heavily used by
> sparse-checkout users where the same confusion just doesn't apply.
>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  Documentation/git-ls-files.txt | 28 +++++++++++++++-------------
>  1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> index f89ab1bfc98..3886d58d178 100644
> --- a/Documentation/git-ls-files.txt
> +++ b/Documentation/git-ls-files.txt
> @@ -137,25 +137,27 @@ OPTIONS
>         with `-s` or `-u` options does not make any sense.
>
>  -t::
> -       This feature is semi-deprecated. For scripting purpose,
> -       linkgit:git-status[1] `--porcelain` and
> +       Show status tags together with filenames.  Note that for
> +       scripting purposes, linkgit:git-status[1] `--porcelain` and
>         linkgit:git-diff-files[1] `--name-status` are almost always
>         superior alternatives, and users should look at
>         linkgit:git-status[1] `--short` or linkgit:git-diff[1]
>         `--name-status` for more user-friendly alternatives.
>  +
>  --
> -This option identifies the file status with the following tags (followed by
> -a space) at the start of each line:
> -
> -       H::     cached
> -       S::     skip-worktree
> -       M::     unmerged
> -       R::     removed/deleted
> -       C::     modified/changed
> -       K::     to be killed
> -       ?::     other
> -       U::     resolve-undo
> +This option provides a reason for showing each filename, in the form
> +of a status tag (which is followed by a space and then the filename).
> +The status tags are all single characters from the following list:
> +
> +       H::     tracked file that is not either unmerged or skip-worktree
> +       S::     tracked file that is skip-worktree
> +       M::     tracked file that is unmerged
> +       R::     tracked file with unstaged removal/deletion
> +       C::     tracked file with unstaged modification/change
> +       K::     untracked paths which are part of file/directory conflicts
> +               which prevent checking out tracked files
> +       ?::     untracked file
> +       U::     file with resolve-undo information
>  --
>

Good to see these tags describe are changed, especially "K" (reader don't know what is "to be killed")

Maybe we should mention which option will output these tags? e.g. default -> "H"/"S" ,`--other` -> "?", `--modified` -> "C", `--killed` -> "K"...

>  -v::
> --
> gitgitgadget
>
Elijah Newren· Jan 14, 2023, 20:26 UTC · re: ZheNing Hu · lore

Re: [PATCH 3/4] ls-files: clarify descriptions of status tags for -t

On Sat, Jan 14, 2023 at 12:27 AM ZheNing Hu <adlternative@gmail.com> wrote:
Show 81 quoted lines
>
> Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> 于2023年1月13日周五 12:41写道:
> >
> > From: Elijah Newren <newren@gmail.com>
> >
> > Much like the file selection options we tweaked in the last commit, the
> > status tags printed with -t had descriptions that were easy to
> > misunderstand, and for many of the same reasons.  Clarify them.
> >
> > Also, while at it, remove the "semi-deprecated" comment for "git
> > ls-files -t".  The -t option was marked as semi-deprecated in 5bc0e247c4
> > ("Document ls-files -t as semi-obsolete.", 2010-07-28) because:
> >
> >     "git ls-files -t" is [...] badly documented, hence we point the
> >     users to superior alternatives.
> >     The feature is marked as "semi-obsolete" but not "scheduled for removal"
> >     since it's a plumbing command, scripts might use it, and Git testsuite
> >     already uses it to test the state of the index.
> >
> > Marking it as obsolete because it was easily misunderstood, which I
> > think was primarily due to documentation problems, is one strategy, but
> > I think fixing the documentation is a better option.  Especially since
> > in the intervening time, "git ls-files -t" has become heavily used by
> > sparse-checkout users where the same confusion just doesn't apply.
> >
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> >  Documentation/git-ls-files.txt | 28 +++++++++++++++-------------
> >  1 file changed, 15 insertions(+), 13 deletions(-)
> >
> > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > index f89ab1bfc98..3886d58d178 100644
> > --- a/Documentation/git-ls-files.txt
> > +++ b/Documentation/git-ls-files.txt
> > @@ -137,25 +137,27 @@ OPTIONS
> >         with `-s` or `-u` options does not make any sense.
> >
> >  -t::
> > -       This feature is semi-deprecated. For scripting purpose,
> > -       linkgit:git-status[1] `--porcelain` and
> > +       Show status tags together with filenames.  Note that for
> > +       scripting purposes, linkgit:git-status[1] `--porcelain` and
> >         linkgit:git-diff-files[1] `--name-status` are almost always
> >         superior alternatives, and users should look at
> >         linkgit:git-status[1] `--short` or linkgit:git-diff[1]
> >         `--name-status` for more user-friendly alternatives.
> >  +
> >  --
> > -This option identifies the file status with the following tags (followed by
> > -a space) at the start of each line:
> > -
> > -       H::     cached
> > -       S::     skip-worktree
> > -       M::     unmerged
> > -       R::     removed/deleted
> > -       C::     modified/changed
> > -       K::     to be killed
> > -       ?::     other
> > -       U::     resolve-undo
> > +This option provides a reason for showing each filename, in the form
> > +of a status tag (which is followed by a space and then the filename).
> > +The status tags are all single characters from the following list:
> > +
> > +       H::     tracked file that is not either unmerged or skip-worktree
> > +       S::     tracked file that is skip-worktree
> > +       M::     tracked file that is unmerged
> > +       R::     tracked file with unstaged removal/deletion
> > +       C::     tracked file with unstaged modification/change
> > +       K::     untracked paths which are part of file/directory conflicts
> > +               which prevent checking out tracked files
> > +       ?::     untracked file
> > +       U::     file with resolve-undo information
> >  --
> >
>
> Good to see these tags describe are changed, especially "K" (reader
> don't know what is "to be killed")
>
> Maybe we should mention which option will output these tags?
> e.g. default -> "H"/"S" ,`--other` -> "?", `--modified` -> "C",
> `--killed` -> "K"...
We could, but...
  * It's H/S/M, not just H/S that is shown by default.
  * It gets weird because other options aren't added to the default,
so if someone specifies "-m" then suddenly H/S/M go away...unless they
also specify "-c".

Trying to explain all that feels like we're getting close to repeating the documentation of the individual options. But maybe we could just ignore everything around default behavior and find a way to be brief such as with:

    Note that H, S, and M entries are shown with --cached; R entries
    are shown with --deleted, C entries are shown with --modified, K
    entries are shown with --killed, ? entries are shown with
    --others, and U entries are shown with --resolve-undo.

I'm not sure if I like the documentation better with or without this added paragraph. What do others think?

ZheNing Hu· Jan 16, 2023, 17:21 UTC · re: Elijah Newren · lore

Re: [PATCH 3/4] ls-files: clarify descriptions of status tags for -t

Elijah Newren <newren@gmail.com> 于2023年1月15日周日 04:27写道:
Show 101 quoted lines
>
> On Sat, Jan 14, 2023 at 12:27 AM ZheNing Hu <adlternative@gmail.com> wrote:
> >
> > Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> 于2023年1月13日周五 12:41写道:
> > >
> > > From: Elijah Newren <newren@gmail.com>
> > >
> > > Much like the file selection options we tweaked in the last commit, the
> > > status tags printed with -t had descriptions that were easy to
> > > misunderstand, and for many of the same reasons.  Clarify them.
> > >
> > > Also, while at it, remove the "semi-deprecated" comment for "git
> > > ls-files -t".  The -t option was marked as semi-deprecated in 5bc0e247c4
> > > ("Document ls-files -t as semi-obsolete.", 2010-07-28) because:
> > >
> > >     "git ls-files -t" is [...] badly documented, hence we point the
> > >     users to superior alternatives.
> > >     The feature is marked as "semi-obsolete" but not "scheduled for removal"
> > >     since it's a plumbing command, scripts might use it, and Git testsuite
> > >     already uses it to test the state of the index.
> > >
> > > Marking it as obsolete because it was easily misunderstood, which I
> > > think was primarily due to documentation problems, is one strategy, but
> > > I think fixing the documentation is a better option.  Especially since
> > > in the intervening time, "git ls-files -t" has become heavily used by
> > > sparse-checkout users where the same confusion just doesn't apply.
> > >
> > > Signed-off-by: Elijah Newren <newren@gmail.com>
> > > ---
> > >  Documentation/git-ls-files.txt | 28 +++++++++++++++-------------
> > >  1 file changed, 15 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> > > index f89ab1bfc98..3886d58d178 100644
> > > --- a/Documentation/git-ls-files.txt
> > > +++ b/Documentation/git-ls-files.txt
> > > @@ -137,25 +137,27 @@ OPTIONS
> > >         with `-s` or `-u` options does not make any sense.
> > >
> > >  -t::
> > > -       This feature is semi-deprecated. For scripting purpose,
> > > -       linkgit:git-status[1] `--porcelain` and
> > > +       Show status tags together with filenames.  Note that for
> > > +       scripting purposes, linkgit:git-status[1] `--porcelain` and
> > >         linkgit:git-diff-files[1] `--name-status` are almost always
> > >         superior alternatives, and users should look at
> > >         linkgit:git-status[1] `--short` or linkgit:git-diff[1]
> > >         `--name-status` for more user-friendly alternatives.
> > >  +
> > >  --
> > > -This option identifies the file status with the following tags (followed by
> > > -a space) at the start of each line:
> > > -
> > > -       H::     cached
> > > -       S::     skip-worktree
> > > -       M::     unmerged
> > > -       R::     removed/deleted
> > > -       C::     modified/changed
> > > -       K::     to be killed
> > > -       ?::     other
> > > -       U::     resolve-undo
> > > +This option provides a reason for showing each filename, in the form
> > > +of a status tag (which is followed by a space and then the filename).
> > > +The status tags are all single characters from the following list:
> > > +
> > > +       H::     tracked file that is not either unmerged or skip-worktree
> > > +       S::     tracked file that is skip-worktree
> > > +       M::     tracked file that is unmerged
> > > +       R::     tracked file with unstaged removal/deletion
> > > +       C::     tracked file with unstaged modification/change
> > > +       K::     untracked paths which are part of file/directory conflicts
> > > +               which prevent checking out tracked files
> > > +       ?::     untracked file
> > > +       U::     file with resolve-undo information
> > >  --
> > >
> >
> > Good to see these tags describe are changed, especially "K" (reader
> > don't know what is "to be killed")
> >
> > Maybe we should mention which option will output these tags?
> > e.g. default -> "H"/"S" ,`--other` -> "?", `--modified` -> "C",
> > `--killed` -> "K"...
>
> We could, but...
>
>   * It's H/S/M, not just H/S that is shown by default.
>   * It gets weird because other options aren't added to the default,
> so if someone specifies "-m" then suddenly H/S/M go away...unless they
> also specify "-c".
>
> Trying to explain all that feels like we're getting close to repeating
> the documentation of the individual options.  But maybe we could just
> ignore everything around default behavior and find a way to be brief
> such as with:
>
>     Note that H, S, and M entries are shown with --cached; R entries
>     are shown with --deleted, C entries are shown with --modified, K
>     entries are shown with --killed, ? entries are shown with
>     --others, and U entries are shown with --resolve-undo.
>

What you mean is that each tag will appear in which commands, rather than each command will have which tags. I think this segment is pretty good.

> I'm not sure if I like the documentation better with or without this
> added paragraph.  What do others think?
Elijah Newren via GitGitGadget· Jan 13, 2023, 04:41 UTC · re: Elijah Newren via GitGitGadget · lore

[PATCH 4/4] ls-files: guide folks to --exclude-standard over other --exclude* options

From: Elijah Newren <newren@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
---
 Documentation/git-ls-files.txt | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
Show changes to Documentation/git-ls-files.txt +5 −2
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 3886d58d178..1abdd3c21c5 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -119,7 +119,8 @@ OPTIONS
 
 --exclude-per-directory=<file>::
 	Read additional exclude patterns that apply only to the
-	directory and its subdirectories in <file>.
+	directory and its subdirectories in <file>.  Deprecated; use
+	--exclude-standard instead.
 
 --exclude-standard::
 	Add the standard Git exclusions: .git/info/exclude, .gitignore
@@ -291,7 +292,9 @@ traversing the directory tree and finding files to show when the
 flags --others or --ignored are specified.  linkgit:gitignore[5]
 specifies the format of exclude patterns.
 
-These exclude patterns come from these places, in order:
+Generally, you should just use --exclude-standard, but for historical
+reasons the exclude patterns can be specified from the following
+places, in order:
 
   1. The command-line flag --exclude=<pattern> specifies a
      single pattern.  Patterns are ordered in the same order
-- 
gitgitgadget

← back to recent threads