Jens Lehmann <Jens.Lehmann@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html