Re: What's cooking in git.git (Feb 2015, #06; Sun, 22)

[Jeff King <peff@peff.net>]

On Mon, Feb 23, 2015 at 11:00:21AM -0800, Junio C Hamano wrote:

> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
> > status, status -s and the like are in an ordinary user's tool box.
> > ls-files isn't, at least not with "-t", which we even mark as deprecated.
> >
> > That makes me wonder, though, how difficult it would be to
> > wt_status_collect_unchanged() and to leverage the status machinery
> > rather than ls-files.
> 
> Good point.  wt-status feels like a much better infrastructure to
> build on than "ls-files -t", which should die ;-).  Especially if
> the command is interested in showing the state of the working tree
> files relative to the tree of HEAD, as "ls-files" is purely between
> the index and the working tree.

I had to look up "-t", having never used it myself. ;)

What I noticed in the manpage was rather gross:

   -t
       This feature is semi-deprecated. For scripting purpose, git-status(1)--porcelain
       and git-diff-files(1)--name-status are almost always superior alternatives, and
       users should look at git-status(1)--short or git-diff(1)--name-status for more
       user-friendly alternatives.

It looks like asciidoc sucks up the space between a linkgit macro and
the next word. I can fix it with "{nbsp}", but I'm not sure if there's a
better way.

It's also rather hard to read the commands as intended with the "(1)"
stuck there. I'm tempted to just make this `git status --porcelain` and
drop the link entirely, but I guess it is helping people who read the
HTML version.

-Peff