On Thu, May 24, 2012 at 7:14 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> Maybe the subject should rather be: >> "submodule: document failures handling relative superproject origin URLs" > Jens: Sure. > > I recall correctly, the original use case for relative URL entries in the > .gitmodules file (to be copied to .git/config as submodule.$name.path) was > so that by looking at the top-level, the locations of the origins for > submodule repositories can be known from where the top-level was cloned. > The above cases do not seem to be relevant, so in the sense, they are of > secondary importance (and I do not find the "sneakernet tool" example > convincing---the sneakernet tool that is distributed in the scenario can > be written differently so that it does not require the other repositories > to be named relative to it). Agreed, that this is not required for the original use case. In the 'sneakernet tool' case, it makes sense for me to have ./mnt/usb around in any case (for the purposes of repos that are being managed by the sneakernet tool). Since that link exists, I can use it for the purposes of managing the tool's own origin repo and doing so does, I think, reduce the number of configuration items I have to tweak to the absolute minimum, but you are right that I don't absolutely have to do it that way. > > As long as you and submodule stakeholders believe this is a reasonable > addition and does not break the existing use cases, I am perfectly fine > with it, though. Ok, thanks for that. Whatever the use case, I think the change is a positive if simply because, by respecting an implicit invariant, it makes the behaviour consistent and predictable. I'll fix the tests, per Jens and your comments and resubmit. Jens: thanks for the review. Regards, jon. -- 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