Re: [PATCH] submodule: teach "foreach" command a --revision <tree-ish> option

From: Jay Soffian <jaysoffian@gmail.com>
Date: Oct 9, 2012, 06:50 UTC
Message-ID: <CAG+J_Dw1iXJfgkmA2V-L11xCOOxO57U4Dh7=h7AzkFUqLc55=w@mail.gmail.com>
In-Reply-To: <7v4nm4i37u.fsf@alter.siamese.dyndns.org>

On Tue, Oct 9, 2012 at 2:12 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 23 quoted lines

> Junio C Hamano <gitster@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 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.