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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 28, 2010, 23:20 UTC
Message-ID: <7vsjzp9a69.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqfwvqdjes.fsf@bauges.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

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

That is exactly why I mentioned "Changes staged for commit" in the first part of my message.

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

If we had "git reset HEAD -- <path>" as a synonym for "git unstage", perhaps. I always hesitate to suggest that, fearing if that synonym would always work, especially when you are not just dealing with your own changes (iow, doing something more than "I have clean checkout, and I edited some files, and I may have run 'git add' on some of them"). I do not think of a situation that the synonym wouldn't work offhand, but that of course does not mean it would always work.

Provided if such "git unstage" can be given as a counterpart of "git stage", it may be fine to advocate the verb "stage". But otherwise, I'd rather not to see the verb advocated in this way.

Notice that my rewording was crafted in such a way, rather carefully, so that we do not have to say "stage" anywhere.

Show 13 quoted lines

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

Well, I was aiming for the same. It is not the "files" but the changes that matter, but what we list are files. What we want to say here is that your changes are two kinds, and the ones to be committed appear in these paths, and the ones to be left behind appear in these paths (that can be overlapping with the former).

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

You could do s/Files with/With/ to shorten them.  Or perhaps

    Changes to be committed are in:
        new file: foo.c
    Changes that will be left out are in:
        modified: foo.c