Re: [PATCH 2/4] Improve cached content header of status output

Andy Whitcroft writes:
 > Junio C Hamano wrote:
 > > Juergen Ruehle <j.ruehle@bmiag.de> writes:
 > >> Does this better reflect that git tracks content and not files?
 > >>
 > >> # Changes to these files will be committed:
 > >>
 > >> # Changes to these files are not marked for commit:
 > > 
 > > One of the goals is to find a pair of messages that make sense
 > > when the same file appears on both lists.
 > 
 > Doh, double changes ... yes.
 > 
 > I am not sure it is possible to sanely textualise that subtlety in a
 > single line.  I wonder if its worth splitting this lot into three.
 > Basically those files on list one, those on list two and those on both.
 > 
 > Anyhow, lets see if we can textualise:
 > 
 > # Changes to these files will be committed:
 > 
 > # The latest changes to these files will not be committed:
 > 
 > The first here still implies its the latest changes.  I can not
 > trivially word round that.  Perhaps we could mention staging?
 > 
 > # Staged changes for these files will be commited:
 > 
 > # These files have unstaged changes which will not be committed:
 > 
 > >> BTW: how about also adding a hint how to review the changes in
 > >> question (i.e. diff --cached and diff; as an alternative to diff
 > >> --cached we could just advertise the --verbose switch to status and
 > >> commit).
 > > 
 > > Sounds sane.

Together with an appropriate second line it is looking good to me

# Staged changes for these files will be commited: # (use --verbose to review and "git reset HEAD <file>..." to unstage)

# These files have unstaged changes which will not be committed: # (Use "git diff" to review and "git add <file>..." to stage for commit)

Perhaps we do not even need to mention files?

# Staged changes to be commited: # (use --verbose to review and "git reset HEAD <file>..." to unstage)

# Unstaged changes to the working directory which will not be committed: # (Use "git diff" to review and "git add <file>..." to stage for commit)