Junio C Hamano [off-list ref] 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?
On Tue, Oct 9, 2012 at 2:12 AM, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
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.