Junio C Hamano <gitster@xxxxxxxxx> writes: > A few points I haven't managed to think about, decide, nor test, are: > > - What should its exit code be? Should it be consistent with the > traditional "git status" at least when no paths are given, signallying > failure when nothing is staged for committing, so that ancient out of > tree scripts people may have written would not break too badly when we > make the switch? > > - What should its default mode of output be? Do people prefer "svn st" > style short-format output, or should we stay verbose and explanatory? > > - Is it handling corner cases correctly? e.g. Does it operate correctly > when run from a subdirectory? How should it handle submodules? Before > the initial commit? Use of colors? Just a quick status update, lest others waste too much time staring at the series I posted last night. - Leading and trailing comments (e.g. "On branch foo", "Initial commit", "# No changes", ...) were missing. - Did not honor -v to show "diff --cached". - Subdirectory behaviour (status.relativepath configuration) was broken. I have a version that fixes the above, and exits 0 when there is no error (i.e. does not exit non-zero on clean index). There are existing tests that expect "git status" erroring out on clean index and there are some that depends on "git status paths..." to show preview of a partial commit, which needed to be replaced with "git commit --dry-run", but as far as I can tell, I've took care of them all. I am still feeling uneasy about the exit status change (the test scripts are sources of how people who script around git take their inspirations after all), but I'll send the result out for a review later without changing that back to "exit failure when there is nothing to commit". -- 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