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
>>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
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

Reply via email to