git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4 1/2] submodule: document handling of relative superproject origin URLs

From
Jon Seymour <jon.seymour@gmail.com>
Date
May 23, 2012, 21:55 UTC
Message-ID
<CAH3AnrpBEnF8BGcfGccmbyh_X-7c4CBN2UOq_v9uDMeWbsnNEQ@mail.gmail.com>
In-Reply-To
<7vvcjmzjkv.fsf@alter.siamese.dyndns.org>
On Thu, May 24, 2012 at 7:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 5 quoted lines
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Maybe the subject should rather be:
>> "submodule: document failures handling relative superproject origin URLs"
>
Jens: Sure.
Show 10 quoted lines
>
> 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.
Previous: Jens LehmannNext: Jon Seymour
Message 6 of 10 in “submodule: fix handling of relative superproject origin URLs”
  1. 0/2 submodule: fix handling of relative superproject origin URLsJon Seymour, May 23, 2012
  2. 1/2 submodule: document handling of relative superproject origin URLsJon Seymour, May 23, 2012
  3. Jens LehmannMay 23, 2012
  4. Junio C HamanoMay 23, 2012
  5. Jens LehmannMay 23, 2012
  6. Jon SeymourMay 23, 2012
  7. 2/2 submodule: fix handling of relative superproject origin URLsJon Seymour, May 23, 2012
  8. Jens LehmannMay 23, 2012
  9. Jon SeymourMay 23, 2012
  10. Jon SeymourMay 24, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.