On Sun, Jul 25, 2010 at 00:54, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Hi, > > When last seen[1], this series was a single patch in very rough form, > but there have been almost no functional changes since then. > > The patches suppress most output when “git commit” is run without > stages changed. So instead of > > $ git commit > # On branch master > # Changed but not updated: > # (use "git add <file>..." to update what will be committed) > # (use "git checkout -- <file>..." to discard changes in working directory) > # > # modified: dir1/modified > # > # Untracked files: > # (use "git add <file>..." to include in what will be committed) > # > # actual > # dir1/untracked > # dir2/modified > # dir2/untracked > # expect > # output > # untracked > no changes added to commit (use "git add" and/or "git commit -a") > > which may cause a newcomer to panic, you get > > $ git commit > no changes added to commit (use "git add" and/or "git commit -a") > > which would just cause her to scratch her head or say “oh, right!” > instead. Hopefully these patches will at least provide a reminder to > improve the various "no changes" advice messages. > > Ideas for future work: > > - add some tests > - give the full traditional output if -a or any paths were passed on > the command line. > > Most of the patches are code clarity improvements which is not > strictly related to this topic. > > Patch 6 cleans up the most obvious script to add tests for this in, > though I have not added any tests to it. > > Patch 8 changes commit --dry-run output in a more modest way, to > print the same advice Jeff added to commit proper last month. I > suspect this is a good change, but input from people who script > around commit --dry-run would be welcome. > > Patch 9 is the advertised patch. It should be self-explanatory. > > Thoughts? Firstly. Acked-by on patches 1-8, they're some much needed cleanup. Especially fixing the hairy wt-status.c code and the test fixes. I'm not so sure about 9/9. Every time I make this mistake with "git commit" I find it helpful to be able to just look up to see what I need to stage. But perhaps the wall of text can be confusing to newbies, I don't have a strong opinion on whether it should be included or not. As an aside, isn't this sort of thing (i.e. long notices/help messages) usually hidden behind advice.* nowadays? With the stripped down message nothing tells you how to find out what to add, which the old message did just by including the "git status" output. Anyway, meh, I don't know :) -- 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