clarify ls-files docs
cover 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
Signature · 1 line
gitgitgadget
PATCH 1/4 ls-files: add missing documentation for --resolve-undo option
From: Elijah Newren <[email protected]>
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.
--- Documentation/git-ls-files.txt | 9 +++++++++ 1 file changed, 9 insertions(+)
Documentation/git-ls-files.txt +9 -0
@@ -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::
Signature · 1 line
gitgitgadget
Re: [PATCH 1/4] ls-files: add missing documentation for --resolve-undo option
Quoted 9 lines · Elijah Newren via GitGitGadget <[email protected]> 于2023年1月13日周五 12:41写道：
From: Elijah Newren <[email protected]>
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 sincece74de931d("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.
Quoted 42 lines
Signed-off-by Elijah Newren <[email protected]>--- Documentation/git-ls-files.txt | 9 +++++++++ 1 file changed, 9 insertions(+)Documentation/git-ls-files.txt +9
-1@@ -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
PATCH 2/4 ls-files: clarify descriptions of file selection options
In reply to Elijah Newren via GitGitGadgetFrom: Elijah Newren <[email protected]>
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).
--- Documentation/git-ls-files.txt | 37 ++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 13 deletions(-)
Documentation/git-ls-files.txt +24 -13
@@ -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
Signature · 1 line
gitgitgadget
Re: [PATCH 2/4] ls-files: clarify descriptions of file selection options
Quoted 44 lines · Elijah Newren via GitGitGadget <[email protected]> 于2023年1月13日周五 12:41写道：
From: Elijah Newren <[email protected]>
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 eachgit rm $FILEwe 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 --modifiedwhen there is a file with an unstaged deletion).Signed-off-by Elijah Newren <[email protected]>--- Documentation/git-ls-files.txt | 37 ++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 13 deletions(-)Documentation/git-ls-files.txt +0
-0
Documentation/git-ls-files.txt This merges the file listing in the index with the actual working · line 35
Quoted 8 lines
Documentation/git-ls-files.txt +3
-1@@ -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.
Quoted 4 lines
Documentation/git-ls-files.txt +0
-0OPTIONS ------- -c:: --cached::
Documentation/git-ls-files.txt This merges the file listing in the index with the actual working · line 47
Quoted 10 lines
Documentation/git-ls-files.txt +4
-2- 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.
Documentation/git-ls-files.txt This merges the file listing in the index with the actual working · line 52
Quoted 6 lines
Documentation/git-ls-files.txt +2
-1-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.
Quoted 52 lines
Documentation/git-ls-files.txt +15
-10-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
Re: [PATCH 2/4] ls-files: clarify descriptions of file selection options
Quoted 2 lines · ZheNing Hu
Elijah Newren via GitGitGadget <[email protected]> 于2023年1月13日周五 12:41写道：
[...]
Quoted 7 lines
Quoted 7 lines
Documentation/git-ls-files.txt +0
-0@@ -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.
Quoted 8 lines
Documentation/git-ls-files.txt This merges the file listing in the index with the actual working · line 35
Quoted 6 lines
Documentation/git-ls-files.txt +3
-1One 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.
--deduplicateoption 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.
Quoted 25 lines
Quoted 4 lines
Documentation/git-ls-files.txt +0
-0OPTIONS ------- -c:: --cached::Documentation/git-ls-files.txt This merges the file listing in the index with the actual working · line 47
Quoted 10 lines
Documentation/git-ls-files.txt +4
-2- 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 deletionThis is a nice fix: make it clear to the user that only files in the working tree are deleted, not in the index.
Documentation/git-ls-files.txt This merges the file listing in the index with the actual working · line 52
Quoted 6 lines
Documentation/git-ls-files.txt +2
-1-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)
Quoted 5 lines
Good to mention that deleted files are also modified, otherwise no one looking at the documentation would know that.
Quoted 2 lines
Documentation/git-ls-files.txt +0
-0-o:: --others::
[...]
Thanks for taking a look!
Re: [PATCH 2/4] ls-files: clarify descriptions of file selection options
Quoted 40 lines · Elijah Newren <[email protected]> 于2023年1月15日周日 03:42写道：
Quoted 2 lines · ZheNing Hu
Elijah Newren via GitGitGadget <[email protected]> 于2023年1月13日周五 12:41写道：
[...]
Quoted 7 lines
Quoted 7 lines
Documentation/git-ls-files.txt +0
-0@@ -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.Quoted 8 lines
Documentation/git-ls-files.txt This merges the file listing in the index with the actual working · line 35
Quoted 6 lines
Documentation/git-ls-files.txt +3
-1One 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.
--deduplicateoption 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
deduplicatecan 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.
Quoted 4 lines
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.
Quoted 5 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.
Quoted 33 lines
Quoted 25 lines
Quoted 4 lines
Documentation/git-ls-files.txt +0
-0OPTIONS ------- -c:: --cached::Documentation/git-ls-files.txt This merges the file listing in the index with the actual working · line 47
Quoted 10 lines
Documentation/git-ls-files.txt +4
-2- 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 deletionThis is a nice fix: make it clear to the user that only files in the working tree are deleted, not in the index.
Documentation/git-ls-files.txt This merges the file listing in the index with the actual working · line 52
Quoted 6 lines
Documentation/git-ls-files.txt +2
-1-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)Quoted 5 lines
Good to mention that deleted files are also modified, otherwise no one looking at the documentation would know that.
Quoted 2 lines
Documentation/git-ls-files.txt +0
-0-o:: --others::[...]
Thanks for taking a look!
PATCH 3/4 ls-files: clarify descriptions of status tags for -t
In reply to Elijah Newren via GitGitGadgetFrom: Elijah Newren <[email protected]>
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.
--- Documentation/git-ls-files.txt | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-)
Documentation/git-ls-files.txt +15 -13
@@ -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::
Signature · 1 line
gitgitgadget
Re: [PATCH 3/4] ls-files: clarify descriptions of status tags for -t
Quoted 62 lines · Elijah Newren via GitGitGadget <[email protected]> 于2023年1月13日周五 12:41写道：
From: Elijah Newren <[email protected]>
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 <[email protected]>--- Documentation/git-ls-files.txt | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-)Documentation/git-ls-files.txt +7
-13@@ -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
Documentation/git-ls-files.txt OPTIONS · line 162
Quoted 10 lines
Documentation/git-ls-files.txt +8
-0+ 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"...
Quoted 4 lines
Documentation/git-ls-files.txt +0
-1-v:: --gitgitgadget
Re: [PATCH 3/4] ls-files: clarify descriptions of status tags for -t
Quoted 78 lines · ZheNing Hu
Quoted 62 lines · Elijah Newren via GitGitGadget <[email protected]> 于2023年1月13日周五 12:41写道：
From: Elijah Newren <[email protected]>
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 <[email protected]>--- Documentation/git-ls-files.txt | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-)Documentation/git-ls-files.txt +7
-13@@ -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-worktreeDocumentation/git-ls-files.txt OPTIONS · line 162
Quoted 10 lines
Documentation/git-ls-files.txt +8
-0+ 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")
Quoted 3 lines
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?
Re: [PATCH 3/4] ls-files: clarify descriptions of status tags for -t
Quoted 96 lines · Elijah Newren <[email protected]> 于2023年1月15日周日 04:27写道：
Quoted 78 lines · ZheNing Hu
Quoted 62 lines · Elijah Newren via GitGitGadget <[email protected]> 于2023年1月13日周五 12:41写道：
From: Elijah Newren <[email protected]>
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 <[email protected]>--- Documentation/git-ls-files.txt | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-)Documentation/git-ls-files.txt +7
-13@@ -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-worktreeDocumentation/git-ls-files.txt OPTIONS · line 162
Quoted 10 lines
Documentation/git-ls-files.txt +8
-0+ 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")
Quoted 3 lines
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:
Quoted 5 lines
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.
Quoted 2 lines
I'm not sure if I like the documentation better with or without this added paragraph. What do others think?
PATCH 4/4 ls-files: guide folks to --exclude-standard over other --exclude* options
In reply to Elijah Newren via GitGitGadgetFrom: Elijah Newren <[email protected]>
--- Documentation/git-ls-files.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
Documentation/git-ls-files.txt +5 -2
@@ -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
Signature · 1 line
gitgitgadget