Thread (4 messages) flat view 4 messages, 4 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:49:12

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help