Stefan Beller <sbeller@xxxxxxxxxx> writes: > Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> > --- > git-submodule.sh | 2 +- > t/t7400-submodule-basic.sh | 12 ++++++------ > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/git-submodule.sh b/git-submodule.sh > index 578ec48..eea27f8 100755 > --- a/git-submodule.sh > +++ b/git-submodule.sh > @@ -693,7 +693,7 @@ cmd_update() > # Only mention uninitialized submodules when its > # path have been specified > test "$#" != "0" && > - say "$(eval_gettext "Submodule path '\$displaypath' not initialized > + say >&2 "$(eval_gettext "Submodule path '\$displaypath' not initialized > Maybe you want to use 'update --init'?")" > continue > fi There are quite a few other calls to "say" in this script, and you are changing only this one to emit it to the standard error output. My quick eyeballing of the script tells me that most of them, other than the ones that are used in cmd_status to report the information that the user asked to be shown on the standard output, are of "Now I am doing this" kind fo output, which I feel are the same category as this one that shouldn't be on the standard output. Another thing (which relates to the one in 01/12) is that not all output from this command comes from "say". Perhaps the first thing to do before doing 01/12 is to sift these messages into types and have them consistently use helpers designed for different purposes, e.g. - a progress, like this one, the one in 01/12, and many other uses of "say"; which may want to become e.g. "say_progress". - an error or a warning, like "Could not remove working tree", "not initialized, maybe you want to do 'init' first?"; which may want to become something else e.g. "say_warning". - the real output from the program, e.g. output from cmd_status, would use yet another, e.g. "printf '%s\n'". instead of converting each message that you happened to have noticed. Note that "say" is squelched under GIT_QUIET (i.e. --quiet). The former two helpers we would want to make quiet (or for errors we may not---I don't know offhand). I do not think of any valid reason why we want to squelch the output from cmd_status under --quiet; it is not like the the while loop on the downstream of "list |" pipe tells some status via its exit code. -- 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