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

Jens Lehmann [off-list ref] writes:

Am 09.10.2012 20:24, schrieb Junio C Hamano:
...

quoted

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.

quoted

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

quoted

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.