Am 28.01.2013 19:51, schrieb Junio C Hamano: > Lars Hjemli <hje...@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. >> -'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? > That could be a problem. Is there a good reason why they should use > different definitions of dirtyness? I don't see any (except of course for comparing a gitlink with the HEAD of the submodule, which is an additional condition that only applies to submodules). 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). >> -'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. I like that approach, because the operations are very similar from the user's point of view. But please remember that internally they would work differently, as submodule foreach walks the index and only descends into those submodules that are populated (and contain a .git directory or file) while for-each-repo scans the whole work tree, which makes it a more expensive operation. >> All of these problems are probably solvable, but it would require >> quite some reworking of git-submodule.sh > > Of course some work is needed, but we do not have to convert all the > cmd_foo in git-submodule.sh in one step. For the purpose of > unifying for-each-repo and submodule foreach to deliver the > functionality sooner to the end users, we can go the route to add > only the submodule--foreach builtin, out of which we will get > reusable implementation of module_list and other helper functions we > can leverage later to do other cmd_foo functions. I really like that idea! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
