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

From: Jeff King <peff@peff.net>
Date: Feb 23, 2015, 20:27 UTC
Message-ID: <20150223202752.GA30429@peff.net>
In-Reply-To: <xmqqk2z8tpve.fsf@gitster.dls.corp.google.com>

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

Show 14 quoted lines

> 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