From: Lars Hjemli <hjemli@gmail.com>
Date: Sat, 24 Jan 2009 19:26:05 GMT
Subject: Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
Message-ID: <8c5c35580901241126q2da83f50m1472ed017b92c982@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0901241443270.13232@racer>

On Sat, Jan 24, 2009 at 14:51, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Now, there is still a problem when your submodule is missing the objects
> for the commit your superproject is referring to.
>
> IMO that is a serious issue, as it just asks for confused users.

This made me finally understand your concern (sorry for being slow):
you want the command to behave in a predictable/consistent way while
my implementation would end up making an archive with basically random
content.


>> > - presence of a specific commit in the supermodule is a _lousy_
>> >   indicator that the user wants to include that submodule in the
>> >   archive.
>>
>> This is the issue I tried to address with my
>> `--submodules=[a|c|r][g:<name>]` proposal in the commit message for
>> this patch.
>
> Nope, doing this "in the future" does not please me one bit.
>
> Besides, I find the semantics, uhm, "interesting".  (The other word would
> be "unintuitive".  Why do you have to be so cryptic that I have to read
> the proposal to understand what the heck "c" is about?)

I thought it would be nifty to be able to combine different flags
which would affect the behaviour/semantics of the command, but given
the comments from you and Junio, I think I'll end up with something
like this:

$ git archive --submodules <tree-ish>: Create an archive which
includes the trees of all gitlink entries in <tree-ish>, fail unless
all the required objects are available.

$ git archive --submodules=<group>: Same as above, but only traverse
submodules in the specified group (as defined in $GIT_CONFIG).

--
larsh