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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 28, 2013, 20:34 UTC
Message-ID: <7vlibdvyh3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <5106DBB7.70007@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 16 quoted lines

> Am 28.01.2013 19:51, schrieb Junio C Hamano:
>> 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?
>
> Hmm, I'm not sure how that would work as it looks for gitlinks
> in the index which point to work tree paths.

I was imagining that "foreach --untracked" could go something like this:

 * If you are inside an existing git repository, read its index to
   learn the gitlinks in the directory and its subdirectories.

 * Start from the current directory and recursively apply the
   procedure in this step:

   * Scan the directory and iterate over the ones that has ".git" in
     it:

     * If it is a gitlinked one, show it, but do not descend into it
       unless --recursive is given (e.g. you start from /home/jens,
       find /home/jens/proj/ directory that has /home/jens/proj/.git
       in it.  /home/jens/.git/index knows that it is a submodule of
       the top-level superproject.  "proj" is handled, and it is up
       to the --recursive option if its submodules are handled).

     * If it is _not_ a gitlinked one, show it and descend into it
       (e.g. /home/jens/ is not a repository or /home/jens/proj is
       not a tracked submodule) to apply this procedure recursively.

Of course, without --untracked, we have no need to iterate over the readdir() return values; instead we just scan the index of the top-level superproject.

Show 7 quoted lines

>>> -'git for-each-repo' and 'git submodule foreach' have different
>>> semantics for --dirty and --clean
>
> I'm confused, what semantics of --dirty and --clean does current
> 'git submodule foreach' have? I can't find any sign of it in the
> current code ... did I miss something while skimming through this
> thread? Or are you talking about status and diff here?

I think Lars is hinting that "submodule foreach" could restrict its operation to a similar --dirty/--clean/--both option he has. Of course, the command given to foreach can decide to become no-op by inspecting the submodule itself, so in that sense, --dirty/--clean can be done without, but I think it would make sense to have it in "submodule foreach" even without the "--untracked" option.

> But I think the current for-each-repo
> proposal doesn't allow to traverse repos which contain untracked
> content (and it would be nice if the user could somehow combine
> that with the current --dirty flag to have both in one go).

Perhaps. I personally felt it was really strange that submodule diff and status consider that it is a sin to have untracked and unignored cruft in the submodule working tree, though.