Hi, On Sat, 24 Jan 2009, Lars Hjemli wrote: > On Fri, Jan 23, 2009 at 20:57, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > 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). The fact that a user can ask for some object directly, and that we do not try to validate it in that case has nothing to do with said assumption. If something is pushed to a remote, and the connection fails, some commit could be pushed already, but some of its reachable objects lacking. The user on the remote side can still try to salvage parts by accessing the objects directly, by their name. But the only guarantee that the objects are reachable is to start from a ref. Concretely, if your patch is applied as-is, such a half-pushed state could affect git-archive in a nasty way: even if the user started from a ref, there could be missing objects! > Do you feel it is necessary to perform a reachability check of the > gitlink'd commit before traversing into a submodule tree? No. Because HEAD is a ref, too. 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. > > - 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?) Ciao, Dscho -- 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
