From: Jonathan Nieder Date: Thu, 28 Oct 2010 22:09:56 GMT Subject: Re: [PATCH 01/10] Better "Changed but not updated" message in git-status Message-ID: <20101028220956.GC16125@burratino> In-Reply-To: <7vaaly9eji.fsf@alter.siamese.dyndns.org> Junio C Hamano wrote: > Jonathan Nieder writes: >> # Changes to be committed: >> # (use "git reset HEAD ..." 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 ..." 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 -- ..." to unstage) # # new file: foo.c # # Changes not to be committed: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." 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.