Jens Lehmann <jens.lehm...@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
> 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.
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