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

From: Jeff King <peff@peff.net>
Date: Jul 27, 2010, 19:58 UTC
Message-ID: <20100727195832.GA11717@coredump.intra.peff.net>
In-Reply-To: <1280162391-18701-1-git-send-email-Matthieu.Moy@imag.fr>

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

Show 5 quoted lines

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

Show 6 quoted lines

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