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

Jens Lehmann [off-list ref] writes:

Am 28.01.2013 19:51, schrieb Junio C Hamano:

quoted

Lars Hjemli [off-list ref] writes:

quoted

quoted

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.

quoted

quoted

-'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.