Jay Soffian <jaysoffian@xxxxxxxxx> writes: > On Tue, Oct 9, 2012 at 2:12 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >>> Assuming that the above guess is correct (which is a huge >>> assumption, given the lack of clarity in the description), I think >>> the feature might make sense. The example would have been a lot >>> easier to follow if it were something like this: >>> >>> $ git submodule foreach --revision v1.0 'git grep -e frotz $sha1' >> >> Imagine you have a checkout of v2.0 of the superproject in your >> working tree, and you run "git submodule foreach --revision v1.0". >> Further imagine a submodule S that used to exist back when the >> superproject was at v1.0 no longer exists in the current codebase >> (hence there is no such submodule in the working tree). >> >> Shouldn't the above "foreach ... grep" still try to find 'frotz' in >> the submodule S that was bound to v1.0 of the superproject? >> >> Given that your patch does not touch the part of cmd_foreach where >> it decides which submodule to descend into, it still will base its >> decision solely on the set of submodules that are bound to and have >> been "git submodule init"ed in the version of the superproject that >> is _currently_ checked out, no? > > That's a good observation. My use-case for this (poorly explained in > ... > As you previously stated, I need to improve the documentation that > goes along with this patch, so I'll call-out this limitation. I'm not > sure what else can be done. You can't descend into a submodule that > isn't there. As recent "submodule rm" work by Jens indicates, since 501770e (Move git-dir for submodules, 2011-08-15), you should be able to peek into submodules that have been "git submodule init"ed but do not exist in the current checkout of the superproject. I think the right approach to implement this "recurse foreach in the superproject tree that is not checkout out to the working tree" feature should be: - Advertise it so that it is crystal clear that the command run by "foreach" may have to run in a bare repository of submodule to look at submodule's commit bound to the historical tree of the superproject; - Anytime you look at .gitmodules in the superproject, read from the historical tree's .gitmodules instead of from the working tree (I think this is necessary in order to get the $sm_name vs $sm_path mapping right); and - Locate submodule's $GIT_DIR in $GIT_DIR/modules/$sm_name of the superproject that corresponds to the submodule found in the historical tree in the superproject (or if it is the same repository as that is currently checked out, use $sm_path/.git), and error out when it is not available. An implementation that works only when all the submodules necessary in the historical tree in the superproject are still in the current checkout of the superproject may be fine as a quick throw-away hack, and it may even be acceptable as a good first step towards the real feature, but at least it needs to be protected by an error checking upfront (perhaps running "diff-tree -r" between the index and the historical tree to make sure there are no removed submodules that existed in the historical tree), if it does not bother to check with $GIT_DIR/modules/$sm_name in the superproject. Jens, anything I missed? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html