On Sat, Jan 24, 2009 at 14:51, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
