Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
- From
- Lars Hjemli <hjemli@gmail.com>
- Date
- Jan 24, 2009, 19:26 UTC
- 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:
Show 5 quoted lines
> > 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.
Show 13 quoted lines
>> > - 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