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

[Lars Hjemli <hjemli@gmail.com>]

On Fri, Jan 23, 2009 at 21:50, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>> 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