At 10:57 -0700 08 Apr 2013, Junio C Hamano <gitster@xxxxxxxxx> wrote:
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.
Yes, I agree that it's not limited to submodules. The commit message for the second part of this series only mentioned submodules because I suspect that is by far the most common use of gitfiles. The commit message for the first didn't even mention submodules at all, they were only brought up because I was asked about what lead to me having an issue.
Blindly using .git at the root level of submodule checkout as a reference is what I was recommending against as a general precaution.
I agree with that. But I still don't think it's relevant to this patch series.
You may be dealing with an old-style submodule checkout.
No, the submodule in question was done with the new style. If it were an old-style checkout my attempt to clone using that as a reference would have worked without issue (at least at clone time).
-- 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