Ævar Arnfjörð Bjarmason wrote: > But I don't know, the "git commit" output doesn't confuse me so I'm > not in the target audience. For what it’s worth, I had three scenarios in mind: Getting started --------------- One way to learn a program is to just try things. Some people take this practice to an extreme and unforunately (1) would expect “git commit” to do the same thing as “cvs commit” and (2) would not want to read a manual or a long stream of text when it does not do so. I hope we can streamline that process somehow, for example by starting the output with the error message: $ git commit fatal: no changes added to commit hint: use 'git add' and 'git reset' to update what will be committed hint: you have 37 untracked files; use 'git status' to list them 24-line terminal ---------------- When I forget to stage changes, the previous output in the terminal’s scrollback buffer may give a reminder of what those changes were. The current “git status” output makes that information harder to find. For the same reason, I basically never use git status without -s. Before status --short existed, I used diff-files and ls-files -o. Now I generally use “add -u”, “diff --cached”, and “add/reset -p”. Need reminder of changes ------------------------ Some people forget where they are and would be confused if “git commit” just failed without explaining why. They need an indication of what just happened and what they need to try to do to fix it up. For such people, the existing output is fine. With a successful series, the new output would also be fine, and running “git checkout” or “git status” would seem the most natural thing in the world rather than an imposition. Hope that helps. Jonathan -- 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