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