Lars Hjemli <hjemli@xxxxxxxxx> writes:
> On Sun, Jan 18, 2009 at 16:48, Johannes Schindelin
> <Johannes.Schindelin@xxxxxx> wrote:
> ...
>> Seems you want to fall back to look in the superproject's object database.
>> But I think that is wrong, as I have a superproject with many platform
>> dependent submodules, only one of which is checked out, and for
>> convenience, the submodules all live in the superproject's repository.
>
> Actually, I want this to work for bare repositories by specifying the
> submodule odbs in the alternates file. So if the current submodule odb
> wasn't found my plan was to check if the commit object was accessible
> anyways but don't die() if it wasn't.
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.
--
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
