On Tue, Oct 9, 2012 at 2:12 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Junio C Hamano <gits...@pobox.com> 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

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

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

Reply via email to