Re: Fwd: git status options feature suggestion

From: Jeff King <peff@peff.net>
Date: Oct 12, 2008, 04:49 UTC
Message-ID: <20081012044900.GA27845@coredump.intra.peff.net>
In-Reply-To: <48EE1F58.2060707@drmicha.warpmail.net>

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

Show 15 quoted lines

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