Re: jc/shortstatus

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

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

It is handy to have both available while asking others help debugging the
version in 'pu', and that is the only reason for the separate command.  It
could have been named 'git frotz' for all I care ;-)

I do not intend to make it another "git merge-recur"; I would actually
want to have it replace "status" before the series goes to 'next'.

I hopefully will have some time to start doing that over the weekend; the
first step would be to rename the branch to jc/1.7.0-status and get rid of
cmd_status() from builtin-commit.c.

A few points I haven't managed to think about, decide, nor test, are:

 - What should its exit code be?  Should it be consistent with the
   traditional "git status" at least when no paths are given, signallying
   failure when nothing is staged for committing, so that ancient out of
   tree scripts people may have written would not break too badly when we
   make the switch?

 - What should its default mode of output be?  Do people prefer "svn st"
   style short-format output, or should we stay verbose and explanatory?

 - Is it handling corner cases correctly?  e.g. Does it operate correctly
   when run from a subdirectory?  How should it handle submodules?  Before
   the initial commit?  Use of colors?

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

It would make sense to create a separate builtin-status.c.  I haven't
looked at the dependencies yet, but it shouldn't be too bad.  We'll see.

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

Yes but hopefully it won't be necessary ;-)