Re: git-status too verbose?

From: Junio C Hamano <junkio@cox.net>
Date: Mar 7, 2006, 09:46 UTC
Message-ID: <7v3bhumvt6.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <440D503E.8090007@op5.se>

Andreas Ericsson <ae@op5.se> writes:

Show 23 quoted lines

>> I agree that it would be useful if we had a tool that showed the
>> two status that matter for each file, grouped together on one
>> line, e.g.
>> 			HEAD->index	index->files
>> 	------------------------------------------------
>> 	hello.c		unmodified      modified
>>         world.c		modified	unmodified
>> 	frotz.c		new		unmodified
>>         ...
>> 	garbage.c~	???		n/a
>> for the current index file and the current HEAD commit.
>
> Could we have 'same' or some such instead of 'unmodified'? It's a bit
> close to 'modified' for the eye to find it quickly.
>
>> You obviously need to learn how to read it though.  The first
>> column means what you _would_ commit if you just said "git
>> commit" without doing anything else now; the second column is
>> what you _could_ commit if you did some update-index and then
>> said "git commit" (or ran "git commit" with paths arguments).
>
> Pretty-printing will be easier if the filename is last, and it will
> look a lot neater if all columns are aligned.

Somebody who feels strongly about this can propose a design. Although I am not particularly fond of the current output, I am not volunteering ;-).

It would be nicer if the proposal was accompanied by a patch, but that is not a requirement for discussion.

The points that design would address should include:

 - set of labels (full list)
   modified, same, renamed?, untracked, ...
 - field ordering (good point by Andreas)
   - what to do _if_ we choose to do rename detection?  you need
     two pathnames.
 - alignment (good point by Andreas)