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

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

Jens Lehmann <Jens.Lehmann@web.de> writes:

> Am 09.10.2012 20:24, schrieb Junio C Hamano:
> ...
>> 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;
>
> I think we should even try to enforce that the user shouldn't use
> the work tree at all (although at the moment I can't come up with
> an idea how we could do that), as the work tree *will* be out of
> sync almost always when you need this option.

Very good point.

>>  - 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.
>
> Looking in $GIT_DIR/modules/$sm_name could make sense to tag even
> those submodules which aren't currently populated. But IIRC the
> tags in such repositories could not be pushed using current git
> even when you use the "--recurse-submodules" option because that
> only honors populated submodules. So for now it would suffice to
> only recurse into populated submodules.

There are million reasons why we shouldn't lightly think "recurse
submodules is a good idea", and I think this may be one of them.

But you can always go to $GIT_DIR/modules/$sm_name and push from
there, so I do not see it as a huge problem.

>> Jens, anything I missed?
>
> Nothing I can think of right now, the above is a pretty good summary.
> My gut feeling is that having "git submodule foreach --revision ..."
> recurse through submodules whose work trees are out of sync is pretty
> fragile and could easily lead to inconsistencies. So I tend to think
> adding a custom script to the release process Jay uses which does the
> tagging itself might be a better solution here. Opinions?

Well, I am not a good judge for that, as I've never been a big fan
of "submodule recurse" myself anyway.  But I think an addition that
works only when the user never uses commands that use the working
tree or the index is still a good thing to have.

We could export a magic environment while running foreach script and
make NEED_WORK_TREE check fail when it is set, or something, but we
need to be careful about performance implications.  "foreach" is not
something that is worth sacrificing the general performance over.