Lars Hjemli <hjemli@xxxxxxxxx> 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. -- 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
