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

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>>  # 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

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.

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