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

Lars Hjemli [off-list ref] writes:

On Fri, Jan 23, 2009 at 20:23, Junio C Hamano [off-list ref] wrote:

quoted

Lars Hjemli [off-list ref] writes:

quoted

quoted

quoted

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.

That makes even less sense.  At that point you are mixing a tree with
random state from a work tree, and doing so only for submodules.  If you
want a work tree snapshot, it should be a work tree snapshot, and should
not be labelled as a snapshot out of a tree object of the superproject.

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.

That would be more like an enhanced version of "git archive" that takes
the work tree state, similar to how "git grep" operates on the work tree
today.

I agree that would be useful, but I have a moderately strong suspition
that your "H" hack that includes the work tree state for checked out
submodules into a view that is primarily about the "tree" object in the
superproject, without the same "take from the work tree" semantics for
paths in the superproject, is more harmful than being helpful to the users
in the longer term.  It might be simple to implement, but I do not think
its semantics can be explained sanely.

On Fri, Jan 23, 2009 at 21:50, Junio C Hamano [off-list ref] wrote:

Lars Hjemli [off-list ref] writes:

quoted

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.

That would be more like an enhanced version of "git archive" that takes
the work tree state, similar to how "git grep" operates on the work tree
today.

I agree that would be useful, but I have a moderately strong suspition
that your "H" hack that includes the work tree state for checked out
submodules into a view that is primarily about the "tree" object in the
superproject, without the same "take from the work tree" semantics for
paths in the superproject, is more harmful than being helpful to the users
in the longer term.  It might be simple to implement, but I do not think
its semantics can be explained sanely.

Ok. When someone gets the itch for 'git archive --worktree', it would
be easy enough to resurrect the idea of including the tree of the
currently checked out HEAD in selected submodules.

Do you think the other options makes any sense, i.e. is it any point
in me trying to implement this?

--
larsh