Aaron Schrab <aa...@schrab.com> writes: > At 08:30 -0700 08 Apr 2013, Junio C Hamano <gits...@pobox.com> wrote: >>You switch to a version of the superproject with a plain file at >>dirA/ or there is nothing at dirA. The checkout will fail and you >>need to manually rectify the situation [*1*], but after that is >>done, you do not have any repository at /path/to/super/dirA/.git >>anymore. >> >>That was the reason why I recommended against the practice. > > So you're essentially saying you don't want to support using a > new-world submodule as a reference because using an old-world > submodule as such is likely to be problematic?
In general I am in favor of resolving a gitfile given to --reference when clone interprets it, and have it use the location of the real underlying object store when it grabs objects not in there from the origin and store the location of the real underlying object store in the objects/info/alternates of the newly created repository. But that is not limited to the gitfile used at the root level of a submodule checkout. Blindly using .git at the root level of submodule checkout as a reference is what I was recommending against as a general precaution. You may be dealing with an old-style submodule checkout. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
