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

From: Lars Hjemli <hjemli@gmail.com>
Date: Jan 23, 2009, 20:15 UTC
Message-ID: <8c5c35580901231215q2be36abbla443975cdbb031f0@mail.gmail.com>
In-Reply-To: <7vzlhhu8qo.fsf@gitster.siamese.dyndns.org>

On Fri, Jan 23, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> 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).

Show 12 quoted lines

>
> 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.

Show 10 quoted lines

>
> 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