On 11/4/07, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> "Yin Ping" <pkufranky@xxxxxxxxx> writes:
>
> > In both case, i think the user should be notified about the inconsistence.
> > My patch given in the first letter handles this by two warning messages as
> > follows (where $name is module name)
> >
> > + cd $name >&/dev/null || { echo " Warning: fail to
> > chdir to $name" && exit; }
>
> In that situation, all he needs to know, with respect to the
> submodule, is that the submodule has been updated since his HEAD
> (and that is given by the runstatus output). He does not _care_
> about what the individual commits in the submodule were. It is
> not an error that the information from the submodule cannot be
> shown to him. He _chose_ to ignore the details of that
> submodule by not checking it out to begin with.
>
> Something like this, to be totally quiet, would be more
> appropriate.
>
> for name in $modules
> do
> (
> ... do the range, indexone, headone stuff
> cd "$name" 2>/dev/null || exit 0
> echo "* $name $headone...$indexone:"
> ... whatever log you show
> ) | sed ...
> done
>
Your point is in some cases people think the warning messages are
annoying because they don't care the change details for submodules.
However, in some cases these messages are helpful. And a third kind of
cases is that people care about only part of all submodules.
So, maybe some an switch can be used to turn this on or off (default
off)? For example
# only sm1 and sm2 are cared
git commit --submodule=sm1,sm2
# all submodules are cared
git commit --submodule='*'
> By the way, I do not know about the quoting issues with $modules
> variable in the above illustration, as I am not (yet) discussing
> about the implementation level of details.
>
--
franky
-
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
