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

[Junio C Hamano <gitster@pobox.com>]

Jay Soffian <jaysoffian@gmail.com> writes:

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