Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations

From: Lars Hjemli <hjemli@gmail.com>
Date: Jan 28, 2013, 18:35 UTC
Message-ID: <CAFXTnz6xBMo42jWdqahYX-bnTBucVmQpFPN29X8tGRd7L=g2wQ@mail.gmail.com>
In-Reply-To: <7vham1xktx.fsf@alter.siamese.dyndns.org>

On Mon, Jan 28, 2013 at 6:45 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> As to the pathspec limiting to affect the loop itself, not the
> argument given to the command that is run, I don't think it is
> absolutely needed; I am perfectly fine with declaring that
> for-each-repo goes to repositories in all subdirectories without
> limit, especially if doing so will make the UI issues we have to
> deal with simpler.

Good (since the relative path of each repo will be exported to the child process, that process can perform path limiting when needed).

Show 11 quoted lines

> As to the "option to the command, not to the subcommand, -a option",
> I have been assuming that it was a joke patch, but if "git -a grep"
> turns out to be really useful, "submodule foreach" that iterates
> over the submodules may also want to have such a short and sweet
> mechanism.  Between "for-each-repo" and "submodule foreach", I do
> not yet have a strong opinion on which one deserves it more.
>
> Come to think of it, is there a reason why "for-each-repo" should
> not be an extention to "submodule foreach"?  We can view this as
> visiting repositories that _could_ be registered as a submodule, in
> addition to iterating over the registered submodules, no?

Yes, but I see some possible problems with that approach: -'git for-each-repo' does not need to be started from within a git worktree -'git for-each-repo' and 'git submodule foreach' have different semantics for --dirty and --clean -'git for-each-repo' is in C because my 'git-all' shell script was horribly slow on large directory trees (especially on windows)

All of these problems are probably solvable, but it would require quite some reworking of git-submodule.sh

-- 
larsh