On Fri, Jan 23, 2009 at 20:23, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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? No, when H is specified the tree of the currently checked out submodule commit would be included (this obviously shouldn't be the default mode of operation, hence a flag to trigger it if that is what the user wants). > > 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. Absolutely. > > 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. I would find the H flag practical for my own usage of submodules. I almost never modify the content of the currently checked out submodule but I often check out a different HEAD than what is registered in the gitlink in the superproject (typically due to testing the superproject against different versions of the submodule). And for such a use case, being able to create a tarball of my currently checked out state seems useful to me. Anyways, if we get as far as adding a --submodules option to git archive, I believe its default mode should be to archive the superproject HEAD state together with the gitlink'd state of each submodule registered in .git/config instead of --submodules=c which is what this patch implements. But I wanted to get some feedback on this plan before trying to implement it. -- larsh -- 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
