Re: git-status too verbose?

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]

On Sat, 4 Mar 2006 12:52:17 -0500, "Eric Jaffe" wrote:
> I was wondering if anyone else thinks that git-status should be more
> like "git-diff --name-status". That is,
>   # A a/newfile.c
>   # M a/oldfile.c

Something like that does seem appealing.

There are at least two issues with doing it:

1) It might be tricky coming up with canonical single characters to be
   used consistently within git. For example, git-ls-files currently
   does do some single-character state indication, but it can be
   rather confusing at times. For example:

	State		Option	Character
	-----		------	---------
	Modified	-m	C
	Unmerged	-u	M
	Cached		-c	H

   And that looks like a permanent problem. For legacy reasons,
   I don't think we can change either the options or the output
   characters of git-ls-files. But perhaps we could at least
   agree on a single, consistent mapping for all future uses.

2) In an important sense, git-status is not verbose enough. For
   example, given a single line such as the following:

	modified: some-file

   This could indicate at least two different states for some-file:

	1) Modified and updated into the index

	2) Modified in working tree, but not updated in the index

   Currently, git-status makes this distinction only in the header
   lines for the separate chunks of its output. But, when there are a
   lot of files involved, and things start scrolling, it's sometimes
   "hard" to associate the right header with the file of interest.

   So, what I've wanted from git-status is a complete encoding of the
   file's state on the same line as the output of the filename.  Maybe
   something that uses two characters per file would work well.

   But I don't have a concrete suggestion for that---I don't think
   I've even successfully enumerated all possible file states with git
   yet...

-Carl

PS. If we do tighten up the output of git-status, I'd also vote for
making the per-chunk headers use only 1 line each instead of 2, and
also eliminating the second blank line separating each chunk.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]