Jeff King <peff@xxxxxxxx> writes: > 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. git diff-files --name-status won't show untracked files, while "git ls-files -t -o" will for example. I agree that "git status" does extra work, but that's what you usually want when you want to know the status of files. We already mention "git diff --name-status", so people looking for "git diff-tree --name-status" should be able to find it. > Also, while testing this, I got confused. Does "ls-files -t" even work, > or am I totally misunderstanding it? I tried: Many people tried to understand what "ls-files -t" was supposed to do, including myself, and I'm afraid nobody succeeded. > Shouldn't one of them be marked "C"hanged (I think file2, but that was > what I was double-checking)? You should ask "git ls-files -t -m" if you want to see modified files. I'm afraid we have another proof that we should discourage the use of this feature ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html