Re: [PATCH 01/10] Better "Changed but not updated" message in git-status

Junio C Hamano wrote:

Jonathan Nieder [off-list ref] writes:

quoted

 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #       new file:   foo.c
 #
 # Changes not staged for commit:

[...]

Hmm, perhaps we'd want to restate the first one as well to read

    Changes staged for commit:
      (use "git reset HEAD <path>..." to unstage)

for consistency as well?

My first impression is no.  Since the main purpose of this text is to
be shown by "git commit", it might even make sense to say:

# Changes to be committed:
#   (use "git reset -- <path>..." to unstage)
#
#	new file:    foo.c
#
# Changes not to be committed:
#   (use "git add <path>..." to update what will be committed)
#   (use "git checkout -- <path>..." to discard changes in working
#   directory)
#
#	typechange:  bar.c

Listing by filename gives a false impression that we are talking about the
whole file contents, and looks a bit confusing until it is explained to
you why when the same file appears in both of the first two sections.

Iould be nice if the "staged changes" section gave a hint that there
were unstaged changes present.  Maybe something like the
"unsaved file" indicator used by some text editors:

	new file:    foo.c*

I've been wondering ever since this thread started if we can phrase it
better to make it even less confusing.  E.g.

    Files with changes to be committed:
        new file: foo.c
    Files with changes that won't be committed:
        modified: foo.c

might help reduce the confusion.

I fear that it can be misparsed as (Files with changes) to be committed.
More importantly, I think Matthieu was right earlier: it is not the
files but the changes that matter.

So when changing a file and marking it executable, I would even like to
see:

	modified:    foo.c
	mode change: foo.c

even if that is not what git does today.