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, 19:42 UTC
- Message-ID
- <CAFXTnz4x1K1cwYKWUJK1ExCjGti8vaW_endoJg20wTYUf4C5NQ@mail.gmail.com>
- In-Reply-To
- <7vr4l5w385.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 7:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Lars Hjemli <hjemli@gmail.com> writes: > >>> 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 > > True, but "git submodule foreach --untracked" can be told that it is > OK not (yet) to be in any superproject, no?
Yes.
Show 6 quoted lines
> >> -'git for-each-repo' and 'git submodule foreach' have different >> semantics for --dirty and --clean > > That could be a problem. Is there a good reason why they should use > different definitions of dirtyness?
I suspected that 'submodule foreach --dirty' might want to compare the HEAD sha1 in the submodule against the one recorded in the superproject (similar to what 'git submodule status' does), but such a check could be triggered by a different flag (e.g. --behind/--ahead or something similar).
Show 7 quoted lines
>> -'git for-each-repo' is in C because my 'git-all' shell script was >> horribly slow on large directory trees (especially on windows) > > Your for-each-repo could be a good basis to build a new builtin > "submodule--foreach" that is a pure helper hidden from the end users > that does both; cmd_foreach() in git-submodule.sh can simply delegate > to it.
Ok, I'll rework my patches in this direction. Thanks.
-- larsh