Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Junio C Hamano wrote: >> Jonathan Nieder <jrnieder@xxxxxxxxx> 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html