Jonathan Nieder [off-list ref] writes:
Result looks like:
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: foo.c
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: foo.c
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# bar.c
which is both clearer and more consistent. So for what it's worth,
Acked-by: Jonathan Nieder <redacted>
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?
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.
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.
"Untracked files" section is about the whole file contents, and it can
stay as is.
Junio C Hamano wrote:
Jonathan Nieder [off-list ref] writes:
quoted
# 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
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.
On Thu, 2010-10-28 at 17:09 -0500, Jonathan Nieder wrote:
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
This one gets my vote out of the replacements I've seen. I appreciate
leaving the "git add" idiom untouched.
quoted
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*
Perhaps in the to be/ not to be sections we could indicate the mtime of
staged changes in comparison with those not staged?
staged:
# modified: foo.c 4:30 PM
unstaged
# modified: foo.c 4:50 PM
If we decide to do this I think it should be a separate patch from this
set (functionality change as opposed to a terminology change). It would
however make clear something that Thore initially complained about:
changed but not updated:
I’m still not sure what “update” was ever supposed to mean in this
sentence. I just edited the file, so it’s updated, for crying out
loud!"
http://article.gmane.org/gmane.comp.version-control.git/159287
--
---------------------------------+--------------------------------------
Drew Northup | Technical Support Specialist
University of Maine System | Drew.Northup@Maine.edu
Computing Center | phone: (207) 561-3513
Orono, ME 04469 | fax: (207) 561-3531