Re: Re* git submodule output on invalid command

[David Aguilar <davvid@gmail.com>]

On  0, Junio C Hamano <gitster@pobox.com> wrote:
> Pieter de Bie <pdebie@ai.rug.nl> writes:
> 
> > ..., something like 'git
> > submodule satsus' is valid and should return nothing, because there are
> > no submodules in the 'satsus' path. However, I still feel this should
> > produce a warning.
> >
> > I'm sure there is a nicer way to alert the user than my patch below, which
> > warns if the user did not supply any valid paths. Anyone else got a more
> > satisfying approach?
> 
> "ls-files --error-unmatch" would warn you of mistyped nonexistent paths,
> but "git submodule Makefile" would still catch the Makefile from the
> toplevel superproject happily and will not complain without checking after
> filtering by submodules.
> 
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index 1c39b59..3aae746 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -59,7 +59,12 @@ resolve_relative_url ()
> >  #
> >  module_list()
> >  {
> > -       git ls-files --stage -- "$@" | grep '^160000 '
> > +       git ls-files --stage -- "$@" | grep '^160000 ' ||
> > +       if test -z "$@"; then
> 
> Shell nit; this must be "$*" not "$@", right?

I added the module_list() function when moving the duplicated
code into a separate function.  The code was lifted verbatim.
I can submit a patch cleaning that up if it should indeed use
"$*".  Just let me know.

Thanks,

-- 

	David