[PATCH v2] Document ls-files -t as semi-obsolete.

The behavior of "git ls-files -t" is very misleading (see
http://thread.gmane.org/gmane.comp.version-control.git/126516 and
http://thread.gmane.org/gmane.comp.version-control.git/144394/focus=144397
for examples of mislead users) and 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.

Signed-off-by: Matthieu Moy <redacted>
---
Resurecting a very old patch:

http://thread.gmane.org/gmane.comp.version-control.git/144874

The earlier concerns were:

1) There are valid uses for "git ls-files -t" and
2) If documentation is bad, then it should be improved.

This version should adress 1) by mitigating the wording (deprecated ->
semi-deprecated, "almost always"). To answer 2), I don't think
spending energy documenting a feature that almost nobody uses is worth
it. At least, I'm not going to do it, and since nothing happened for
months, I guess no one else will.

 Documentation/git-ls-files.txt |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 3521637..2cc3243 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt

@@ -106,6 +106,12 @@ 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` is almost always a
+	superior alternative, and users should look at
+	linkgit:git-status[1] `--short` or linkgit:git-diff[1]
+	`--name-status` for more user-friendly alternatives.
+
 	Identify the file status with the following tags (followed by
 	a space) at the start of each line:
 	H::	cached

-- 
1.7.2.19.g9a302.dirty

Sounds good; comments from others?

On Monday 26 July 2010, Matthieu Moy wrote:

I think this breaks formatting. Shouldn't it be more like the following?
(I.e. with a single '+' before "Identify...").

And maybe rephrase the line
"Identify the file status with the following tags (followed by
a space) at the start of each line"
into
"This option identifies..."
just to set apart "semi-deprecation" and "explanation" of the option.

diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 3521637..ef84d41 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt

@@ -106,15 +106,21 @@ OPTIONS
 	with `-s` or `-u` options does not make any sense.
 
 -t::
-	Identify 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
+	This feature is semi-deprecated. For scripting purpose,
+	linkgit:git-status[1] `--porcelain` is almost always a
+	superior alternative, and users should look at
+	linkgit:git-status[1] `--short` or linkgit:git-diff[1]
+	`--name-status` for more user-friendly alternatives.
++
+Identify 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
 
 -v::
 	Similar to `-t`, but use lowercase letters for files

On Mon, Jul 26, 2010 at 06:39:51PM +0200, Matthieu Moy wrote:

The behavior of "git ls-files -t" is very misleading (see
http://thread.gmane.org/gmane.comp.version-control.git/126516 and
http://thread.gmane.org/gmane.comp.version-control.git/144394/focus=144397
for examples of mislead users) and badly documented, hence we point the
users to superior alternatives.

I agree with the goal, but one nit:

 -t::
+	This feature is semi-deprecated. For scripting purpose,
+	linkgit:git-status[1] `--porcelain` is almost always a
+	superior alternative, and users should look at
+	linkgit:git-status[1] `--short` or linkgit:git-diff[1]
+	`--name-status` for more user-friendly alternatives.

Isn't "git diff-files --name-status" the closest plumbing analogue? Git
status actually does a lot of extra work.

Also, while testing this, I got confused. Does "ls-files -t" even work,
or am I totally misunderstanding it? I tried:

  mkdir repo && cd repo && git init &&
  echo content >file1 &&
  echo content >file2 &&
  git add . &&
  git commit -m one &&
  echo content >>file1 &&
  echo content >>file2 &&
  git add file1 &&
  git ls-files -t

which yields:

  H file1
  H file2

Shouldn't one of them be marked "C"hanged (I think file2, but that was
what I was double-checking)?

-Peff