git-status too verbose?

git-status too verbose?

[Eric Jaffe]

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

instead of
  # new file: a/newfile.c
  # modified: a/oldfile.c

This would be similar to cg-status and "svn status", etc.

--
Eric Jaffe <jaffe.eric@gmail.com>

Re: git-status too verbose?

[Carl Worth]

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

Re: git-status too verbose?

[Shawn Pearce]

Carl Worth <cworth@cworth.org> wrote:
> 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

I've played around with this idea a little bit in pg's pg-status
command but I most likely do not have all cases covered.

In general I try to show HEAD<-->index first using uppercase letters
then index<-->working directory second in lowercase letters.

Here's the critical portion of pg-status:

	git-diff-index --cached --name-status HEAD | sed -e 's/ / /'
	if test $index_only  = n
	then
	  git-diff-files --name-status | sed \
		-e 's/      / /' \
		-e 's/^D /g /' \
		-e 's/^M /m /' \
		-e '/^U /d'
	  pg--ls-others | sed 's/^/x /'
	fi

Thus far I've found it useful to behave this way and I haven't run
up against any states which didn't make immediate sense to me.
Here's the documentation I have in pg-status describing what it
can show:

Status indicators (displayed in column 1):

 A : New file has been marked for addition with pg-add.
 D : Existing file has been marked as deleted with pg-rm.
 M : Existing file has been modified (and is known to the index).
 U : File still has unmerged hunks, see pg-resolved.

 m : Existing file (maybe) has been modified (use -q to know for sure).
 g : File has been removed from directory but not marked with pg-rm.
 x : File is not known to repository and isn't being ignored.

-- 
Shawn.

Re: git-status too verbose?

[Junio C Hamano]

"Eric Jaffe" <jaffe.eric@gmail.com> writes:

> 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
>
> instead of
>   # new file: a/newfile.c
>   # modified: a/oldfile.c

Why do people think mysterious single letter abbreviation is
better than spelled out words in an output meant for human
consumption?

The tag letters you get from "ls-files -t" are inconsistent with
what you would get from all the other git tools for historical
reasons, so if you want to do a single-letter abbreviation, you
first need to come up with a set of letters and translate the
output from ls-files -t into that.

Although I personally like Carl's suggestion a lot, I am still
ambivalent about it a bit.

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.

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

I think it is a valid view for people who know how internally
git barebone porcelain works using git lowlevel, and to them
(including me), the above is more concise and appear useful.

But I am not sure if it is appropriate for "git status", which
is the tool for commit-preview.  The index "git status" is
showing is the index you would get if you were to run "git
commit" with the same set of parameters, exactly for that reason
(e.g. "git status -a -v" would see "unmodified" for all tracked
paths in index->files column in the above output). 

Re: git-status too verbose?

[Joshua N Pritikin]

On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:
> 			HEAD->index	index->files
> 	------------------------------------------------
> 	hello.c		unmodified      modified
>         world.c		modified	unmodified
> 	frotz.c		new		unmodified
>         ...
> 	garbage.c~	???		n/a

For what it's worth, this chart immediately made sense to me and I would
prefer it to the current git-status output.

Re: git-status too verbose?

[Karl Hasselström]

On 2006-03-07 11:05:47 +0530, Joshua N Pritikin wrote:

> On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:
>
> >                     HEAD->index     index->files
> >     ------------------------------------------------
> >     hello.c         unmodified      modified
> >     world.c         modified        unmodified
> >     frotz.c         new             unmodified
> >         ...
> >     garbage.c~      ???             n/a
>
> For what it's worth, this chart immediately made sense to me and I
> would prefer it to the current git-status output.

I agree. This kind of status information makes the whole index concept
an order of magnitude less confusing. In a way, it lets you learn what
the index is by example, rather than first having to learn what it is
in order to be able to grok the status information.

Fitting this in 80 columns should be a funny excercise, though. :-)
I'd suggest printing the filename last:

     HEAD->index  index->files
     ------------------------------------------------
     unmodified   modified      hello.c
     modified     unmodified    world.c
     new          unmodified    frotz.c
         ...
     ???          n/a           garbage.c~

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: git-status too verbose?

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1085 bytes --]

Hi,

On Tue, 7 Mar 2006, Karl Hasselström wrote:

> On 2006-03-07 11:05:47 +0530, Joshua N Pritikin wrote:
> 
> > On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:
> >
> > >                     HEAD->index     index->files
> > >     ------------------------------------------------
> > >     hello.c         unmodified      modified
> > >     world.c         modified        unmodified
> > >     frotz.c         new             unmodified
> > >         ...
> > >     garbage.c~      ???             n/a
> >
> > For what it's worth, this chart immediately made sense to me and I
> > would prefer it to the current git-status output.
> 
> I agree. This kind of status information makes the whole index concept
> an order of magnitude less confusing. In a way, it lets you learn what
> the index is by example, rather than first having to learn what it is
> in order to be able to grok the status information.

I beg to differ. The index thing is complex enough as it is. You should 
not shy away potentially customers by such output at such often used 
place.

Ciao,
Dscho

Re: git-status too verbose?

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> Why do people think mysterious single letter abbreviation is
> better than spelled out words in an output meant for human
> consumption?
> 

Familiarity, I suspect.

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

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-status too verbose?

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

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

Re: git-status too verbose?

[Andreas Ericsson]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>>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.
> 

I'll see if I can get around to it tonight.

> The points that design would address should include:
> 
>    - what to do _if_ we choose to do rename detection?  you need
>      two pathnames.

I like the gitk view of these things, "renamed from" and "renamed to", 
although we'll likely want shorter names since the filename part can't 
start before column max_label_name * 2 + 4 if we assume two spaces 
minimum between word-columns. Perhaps mv-to and mv-from?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-status too verbose?

[Linus Torvalds]

On Tue, 7 Mar 2006, Andreas Ericsson wrote:
> > 
> > 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.

I really _really_ hate that table anyway.

What I want to know is "what is committed", and "what is not".

That table makes it really really hard to see what you are committing, if 
you have a hundred files changed that are _not_ being committed. The 
actual committed information will be interspersed in the files you're not 
interested in, and vice versa.

The current commit message is a million times superior, even if it might 
not be as _pretty_.

		Linus

Re: git-status too verbose?

[Carl Worth]

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

On Tue, 7 Mar 2006 10:22:28 -0800 (PST), Linus Torvalds wrote:
> 
> What I want to know is "what is committed", and "what is not".

Agreed. Me too.

> That table makes it really really hard to see what you are committing, if 
> you have a hundred files changed that are _not_ being committed. The 
> actual committed information will be interspersed in the files you're not 
> interested in, and vice versa.

The current sorting and grouping should not be changed.

I just want to be able to know if I'm looking at a section of
"committed" vs. "not committed" files when the headers have scrolled
off.

I think it's really just that one bit of information needed. Maybe a
'*' before the word 'modified' (or 'M' or whatever)?

-Carl

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