Re: Fwd: git status options feature suggestion

On Thu, Oct 09, 2008 at 05:12:24PM +0200, Michael J Gruber wrote:

- people are used to "svn status [-v]" like output which can include
untracked as well as tracked unmodified files; there are other valid
reasons why you would want that info

- porc can't do it: git status can't show ignored files, doesn't use
status letters, can't show files with specific status; git diff
--name-status can't show ignored nor untracked files
[In fact, the description of "git diff" says "files which you could
add", which should include untracked files, but doesn't.]

- plumb uses conflicting letters: git ls-files output conflicts with git
diff --name-status output

So I guess it's time for a usability effort in this area. A few
questions before going about that:

A week or two ago I came across yet another git-status annoyance: it
needs write access to the repository to run (I was helping somebody with
a task on a shared box, and I wanted to run status in their repository
using my account).

I considered submitting a patch to fix this, but I think it is really
more fundamental. I use status to get an overview of what's going on in
a repo, but it is intimately related to a potential commit.

And this bleeds into other areas, too. Why should the "what's going on
in this repo" command prefix all lines with "#"? We would have more
freedom to change the format if it weren't required to be a comment
line in a commit message.

So I think it is probably reasonable to think about a new command (which
would not be called status) that shows this information. What do people
want to see? And in what format? Some things I would want or have seen
requested are:

 - staged and unstaged changes in --name-status format

 - files without changes (with a -v flag).

 - untracked files

 - current branch / detached HEAD (with relationship to tracked branch,
   if any)

And maybe after hashing it out, it turns out it's not that different
from "git status" and we should just stick with that. But I would be
curious to hear proposals.

- I think change of existing behaviour is unavoidable (make ls-files and
diff --name-status consistent). Is that something to do now or rather
before 1.7? Is porc (diff) supposed to be changed or plumb (ls-files)?

I don't think you would want to just change the default; you would
probably add a new option to ls-files to use the --name-status letters,
and then use that in your new porcelain.

- How strong should the tie between git status and git commit be?
Current git status is basically git commit -n, with the usual meaning of
"-n" (such as for prune etc."), not with the current meaning of git
commit -n, sigh...

I think the theoretical tool I mentioned would benefit from breaking
this connection. But I don't know whether it is prudent to take the
"status" name in doing so. Even if we decided to do so, it would
probably happen something like:

  1. Introduce git-wtf, a new status-like tool. Deprecate git-status in
     its current form.

  2. Wait a really long time.

  3. Rename git-wtf to git-status.

So either way, the first step is an alternative replacement command.

-Peff