Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules

[Junio C Hamano <gitster@pobox.com>]

Lars Hjemli <hjemli@gmail.com> writes:

>>> The plan is to fix these limitations by extending --submodules to allow
>>> certain flags/options:
>>> a|c|r     include any|checked out|registered submodules
>>> H         resolve submodule HEAD to decide which tree to include

What do you mean by "decide"?  If HEAD exists (iow, the submodule is
checked out), the tree of the commit recorded in the superproject's
gitlink entry is included in the result?

As I already said before, I doubt it makes much sense in the context of
the current git-archive to base the choise on checkout status.

Unless you are extending git-archive and giving it an ability to write out
the superproject index or the work tree as an archive, that is.

Just like git-grep lets you grep in the work tree files (limited to paths
that appear in the index), or grep in the contents registered to the index
when run with --cached, git-archive could make an archive out of your work
tree files or your index contents.  Such an extension to git-archive may
be quite useful with or without submodules.

In such mode of operation, because you are dealing with the work tree when
run without --cached, it would make sense to say "Ah, the superproject
index wants v1.0 of the submodule, but the work tree has v2.0 of it
checked out, and we are writing out the work tree, so let's include v2.0
instead", and as a side effect of deciding which commit's tree to include
from each submodule, it naturally makes sense to exclude submodules that
are not checked out.

But otherwise I am not so sure what the point of H option would be.