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 the commit message) is as part of a release process, where I wish to apply corresponding tags to the superproject and its submodules like so: $ cd /path/to/superproject $ git tag -m "1.0" v1.0 deadbeef $ git submodule foreach --revision deadbeef \ 'git tag -m "superproject 1.0" superproject-1.0 $sha1' Typically deadbeef may be a day or two behind HEAD and it's nice to be able to tag it and the submodules w/o having to switch everything to a detached HEAD. In my case, tagging and updating submodule revisions are somewhat common, while adding/removing submodules is a rare event. I didn't mention this issue explicitly because I thought it was covered by the existing documentation: "Any submodules defined in the superproject but not checked out are ignored by this command." 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. j. -- 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