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

Jonathan Nieder [off-list ref] writes:

Junio C Hamano wrote:

quoted

Jonathan Nieder [off-list ref] writes:

quoted

quoted

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

[...]

quoted

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

Actually, my formulation also has a subtle advantage: it somehow
teaches the meaning of "staged". By reading "Changes not staged for
commit" close to "Changes to be commited", it makes it rather clear
what "staged for commit" means.

Perhaps changing the hint from "git add" to "git stage" right below
would make that even clearer.

So, I tent to (very slightly) prefer my version.

It would 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'd argue against the syntax, since it kills cut-and-paste, but a
visual indicator could be nice, yes.

quoted

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.

I second that. Furthermore, keeping it short increase the changes that
user will actually read the message.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/