From: Lars Hjemli Date: Sat, 24 Jan 2009 08:44:35 GMT Subject: Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules Message-ID: <8c5c35580901240044y452b465fj94df82fc2b8f7ee9@mail.gmail.com> In-Reply-To: On Fri, Jan 23, 2009 at 20:57, Johannes Schindelin wrote: > > On Fri, 23 Jan 2009, Lars Hjemli wrote: >> >> That's too bad, I hoped on some feedback from you on the part of the >> commit message which you didn't quote: > > Well, you ignored my comments, I might have misunderstood your comments, but I certainly didn't ignore them. I actually tried to come up with a solution that would solve your concerns about which submodules to include in the archive (which is why I hoped for some feedback on that proposal). > so what do you expect me to do? Be happy? > > There are two issues there: > > - presence of a specific commit object being present in the repository > does not necessarily mean that it is reachable by any ref, and therefore > can mean that the tree/blob objects are not reachable, because it could > be an interrupted fetch; This part I agree with. > in all of Git, we try to assume that only > reachable objects are valid objects. I don't think this is true (most git commands accepts their arguments as valid objects without verifying if they are reachable from a ref). Do you feel it is necessary to perform a reachability check of the gitlink'd commit before traversing into a submodule tree? > - 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:]` proposal in the commit message for this patch. I hoped you would find it interesting, given your comments in http://thread.gmane.org/gmane.comp.version-control.git/106167/focus=106235 (i.e. my 'a' flag would match your 'look-in-superprojects-odb', while the 'c', 'r' and 'g' options would address your issues about how to select the correct set of submodules). -- larsh