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

[Lars Hjemli <hjemli@gmail.com>]

On Fri, Jan 23, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
> 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?

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