git-status too verbose?

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>

On Sat, 4 Mar 2006 12:52:17 -0500, "Eric Jaffe" wrote:

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.

Carl Worth <cworth@cworth.org> wrote:

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.

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

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

On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:

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

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

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~

Hi,

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

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

Junio C Hamano wrote:

Familiarity, I suspect.

Could we have 'same' or some such instead of 'unmodified'? It's a bit close to 'modified' for the eye to find it quickly.

Pretty-printing will be easier if the filename is last, and it will look a lot neater if all columns are aligned.

Andreas Ericsson <ae@op5.se> writes:

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)

Junio C Hamano wrote:

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

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?

On Tue, 7 Mar 2006, Andreas Ericsson wrote:

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

On Tue, 7 Mar 2006 10:22:28 -0800 (PST), Linus Torvalds wrote:

Agreed. Me too.

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