jc/shortstatus (was: What's cooking in git.git (Aug 2009, #02; Wed, 12))

From: Jeff King <peff@peff.net>
Date: Aug 15, 2009, 07:09 UTC
Message-ID: <20090815070904.GA23389@coredump.intra.peff.net>
In-Reply-To: <7vtz0co3xe.fsf@alter.siamese.dyndns.org>

On Wed, Aug 12, 2009 at 07:14:53PM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> * jc/shortstatus (Tue Aug 4 23:55:22 2009 -0700) 12 commits
>  - git stat -s: short status output
>  - git stat: pathspec limits, unlike traditional "git status"
>  - git stat: the beginning
>  + wt-status: collect untracked files in a separate "collect" phase
>  + Make git_status_config() file scope static to builtin-commit.c
>  + wt-status: move wt_status_colors[] into wt_status structure
>  + wt-status: move many global settings to wt_status structure
>  + commit: --dry-run
>  + status: show worktree status of conflicted paths separately
>  + wt-status.c: rework the way changes to the index and work tree are
>    summarized
>  + diff-index: keep the original index intact
>  + diff-index: report unmerged new entries
> 
> Slowly progressing.  I've addressed issues pointed out by Jeff in his
> review, and hopefully the whole thing would be ready to go.

I briefly looked over what's in next, and the fixes you made look good to me. I've been running with this series for a little while, and I was very pleased when "git status" showed me a more detailed description of some unmerged paths the other day. :)

For the "git stat" portion still in pu, I have a few comments/questions:

  1. Is "stat" a good name? I worry a little that it is _too_ similar to
     "status", and that will cause confusion while they both exist. So
     something like "git overview" would cause less confusion, and even
     though it sucks to type, it will eventually replace "status" (and
     in the meantime people can make aliases or whatever).

  2. Does it really belong in builtin-commit.c anymore? It seems like
     historical accident that "status" is so closely tied to commit. The
     whole point of the new command is to _not_ be tied; I think of the
     new command more as an extension of 'diff'. Admittedly, users don't
     care where the source is located, but it helps the developers
     understand the relationships between code.

  3. Can you squash in the gitignore patch below? :)

---

diff --git a/.gitignore b/.gitignore
index c446290..14e0f51 100644
--- a/.gitignore
+++ b/.gitignore
@@ -128,6 +128,7 @@ git-show-index
 git-show-ref
 git-stage
 git-stash
+git-stat
 git-status
 git-stripspace
 git-submodule