Re: [PATCH 2/3] Teach read_tree_recursive() how to traverse into submodules

Lars Hjemli <hjemli@gmail.com> writes:

The current submodule design is "do not recurse into them by default without being told" throughout the Porcelain. We can think of various ways for the users to tell which submodules are of interest and which are uninteresting.

The most general solution would be to give a list of submodules you are interested in recursing into from the command line, something like:

    $ git command --with-submodule=path1 --with-submodule=path2...

That approach would work equally "well" with a bare repository or with a non-bare repository, but if you have N submodules, you need to give up to N extra options, which may be cumbersome (meaning, "works equally well" above actually may mean "works equally awkwardly"). One way to solve awkwardness may be to support a mechanism that allows you to use configuration variables to name a group of submodules.

In addition to such configuration variables, you already have one default group of submodules, defined by the way you set up your work tree, when your superproject does have a work tree. Some submodules have repositories cloned in the work tree, while some don't, and the ones without clones can be defined as "uninteresting ones" (to the work tree owner) that are outside the default group. For many work tree oriented operations, it may even make sense to allow that group to be used with a single "git command --with-submodule" (i.e. when you do not say which submodule you mean, that can default to "cloned" group).

I do not know "has an entry in the superproject's alternate list that points to its object store" is a good basis to define another default group useful especially in a bare repository setting; you seem to be suggesting that, and you might be correct.

For "git archive", however, I suspect the "default group based on work tree checkout state" may make the least sense. "git archive HEAD" is expected to give a reproducible dump of the state recorded by the HEAD commit no matter who runs it in what repository, and I think there should be a conscious and explicit instruction from the end user that says "Here is a dump from this commit in the superproject, *BUT* it was made together with contents from this and that submodule". Command line options that list "this and that submodule" is explicit enough, and a configured nickname given to a known group of submodules from the command line may be so as well, but the group based on the checkout state feels a bit too implicit and magical to my taste. The group based on the "has an entry in superproject's alternates" criterion is not much better in this regard, methinks.

Another worrysome thing about "git archive" is that it marks the resulting archive with the commit object name the tarball was taken from. If you allow recursing into an arbitrary subset of submodule, a project with N submodules can produce 2^N different varieties of archive, all marked with the same commit object name from the superproject. That might be a bit too confusing.