Re: [PATCH] - Added recurse command to git submodule

From: Imran M Yousuf <imyousuf@gmail.com>
Date: Jan 10, 2008, 03:27 UTC
Message-ID: <7bfdc29a0801091927v4eb65a60qf5b185924b9d1e44@mail.gmail.com>
In-Reply-To: <7vhchmhhjv.fsf@gitster.siamese.dyndns.org>

On Jan 10, 2008 2:26 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > A possible extension is to specifiy "inter-submodule" paths to the
> > init subcommand, i.e. for a possible KDE layout:
> >   git submodule -r init kdelibs kdelibs/admin
> >
> > This should then recursively initialize the kdelibs submodule and the
> > admin-submodule (in the kdelibs submodule).
>
> Beautiful.

Firstly, thank you for the feedback Junio and Lars. Secondly, I was not planning to add recurse to the init/update command, but your (Lars) suggestion seems really handy; I will implement it in my patch. About auto-initialization, I, as writing, am implementing it to be optional and an extra -i has to be specified if the user wants to do it.

Show 10 quoted lines

>
> > Btw: from my reading of the code, the git-command specified for
> > 'recurse' will be done top-to-bottom: I guess that's what you want for
> > something like 'git submodule recurse diff', but not for something
> > like 'git submodule recurse commit' (but IMHO the latter one should
> > never be executed ;-)
>
> Thanks for raising a very good point.  Yes, some commands
> inherently wants depth first.
>

I could not agree more and in fact, I wanted to leave to the user how they use the recurse command. I basically will be using for status and diff primarily; and may be for creating and checking out branches; but as I said it mostly depends on how the user wants to use it.

Show 9 quoted lines

> While I agree that making a recursive is a grave usage error
> (submodule commit and toplevel commit are logically different
> events and even their commit log message should be different, as
> they talk about changes in logically different levels) from
> project management point of view, I do not think it is something
> a tool has to explicitly forbid the users to do.  I view it as a
> kind of a long rope, a misuse the users can be allowed to
> inflict on themselves if they really wanted to.
>

In fact if I am also thinking whether to add intelligence in such scenarios. What do you think if we choose DF of BF based on the command and options?

Show 12 quoted lines

> Also, some commands cannot be made recursive by driving them
> from a higher level recursive wrapper.  "git submodule recursive
> log" would not make much sense, not only because the order of
> the log entries are output from different invocations would not
> be useful, but because the revision range specifier would need
> to be different in different submodules (e.g. library submodules
> and application submodule will not share version name namespace,
> i.e. "log v1.0..v2.0" is undefined, and worse yet, running "log
> v1.0:path/to/sub..v2.0:path/to/sub" in a submodule when running
> "log v1.0..v2.0" in the toplevel is not a correct solution
> either in general).
>

What is you suggestion in such cases Junio?

-- 
Imran M Yousuf