git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: Mark Levedahl <mlevedahl@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Relative submodule URLs vs. clone URL DWIMming
Date: Fri, 29 Aug 2008 01:01:19 +0200	[thread overview]
Message-ID: <200808290101.20048.johan@herland.net> (raw)
In-Reply-To: <48B6BB49.3000703@gmail.com>

On Thursday 28 August 2008, Mark Levedahl wrote:
> Johan Herland wrote:
> > I'd like to fix this, but I'm not sure whether the fix belongs in
> > builtin-clone.c (i.e. making sure the origin URL is always "correct"
> > wrt. resolving relative submodule URLs), or in git-submodule.sh (i.e.
> > adding smarts when resolving relative submodule URLs against the
> > super-repo's origin URL).
>
> I think the right approach is to start with clone and make it record the
> real url it is using, regardless of what was input. The problem with
> doing this in submodule is that in effect this replicates the search
> logic clone would use, and furthermore could lead to nasty surprises by
> grabbing the wrong submodule in an extreme case of having two
> identically named repositories in different locations on a server.

Thanks for your input. I looked into builtin-clone, and how to make it write
the real origin URL for remote repos (it already does this today for local
repos). But AFAICS, there's no way to get this information from the
transport layer. I assume that the actual repo location is resolved on the
remote side, and simply not communicated back to the local side.

Also, after thinking some more about this, I'm unsure of the practical
implications of this. Let's assume we can actually make "git clone" write
the real URL in all cases (i.e. typically "repo.git" for bare repos
and "repo/.git" for non-bare repos):

If we simply resolve submodule URLs against the _repo_ (i.e. the real origin
URL) and not the work tree (if any), we get results that are coupled to
whether we use bare or non-bare repos: Take, for example, your use
of "../<path>" to make submodules live outside the (bare) superproject. If I
now create a non-bare clone of this, I must move the submodule repos _into_
my work tree, so that the submodule repos are available, if someone tries to
clone from me.

Additionally, when making super/sub repos available for others, I must make
a mental effort to interpret the relative submodule URLs in .gitmodules
against - NOT the work tree in which .gitmodules is located - but rather
against the .git directory which is (most often) one directory level further
down from the .gitmodules file.

Maybe the easiest solution is to add a new config directive called something
like "core.submodules.baseUrl". When set, relative submodule URLs would be
resolved against this instead of the origin URL. When unset, the origin URL
is used as a fallback. Hmm?

Still, it would be nice to have intuitive and consistent behaviour by
default, though...

> I was about to create a patch for submodule to always remove trailing
> "/.git" before resolving, but in fact a user could put the submodule
> .git into the superproject's .git, in a non-bare repository, and then
> gitlink that in the checked out submodule. So, it may also be good to
> define and enforce rules on how relative url naming can be used for this
> purpose. So far, I have only used it for bare repositories using the
> "../<path> form keeping the submodules out of the superproject.

Yes, duplication of such logic is probably a bad idea. Would it be better to
consolidate all this URL DWIMming in one place which is #included from
builtin-clone, git-submodule, git-fetch, and other commands that need this
functionality?

In any case, defining the rules for how relative submodule URLs are supposed
to work would certainly make a good step in the right direction.


Have fun! :)

...Johan


PS: Here are the beginning of a test case for codifying the rules of
relative submodule URL behaviour. Needless to say, the last testcase
currently fails:

diff --git a/t/t7403-submodule-relative.sh b/t/t7403-submodule-relative.sh
new file mode 100755
index 0000000..9c12248
--- /dev/null
+++ b/t/t7403-submodule-relative.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Johan Herland
+#
+
+test_description='Testing repos with relative submodule URLs
+
+This test tries to verify the sanity of working with relative submodule URLs.
+'
+
+. ./test-lib.sh
+
+TRASH_DIR=$(pwd)
+
+#
+# Test setup:
+#  - create the following super-/sub-repository hierarchy:
+#     /
+#     /file
+#     /a submodule/
+#     /a submodule/file
+#
+test_expect_success 'setup' '
+
+	echo file > file &&
+	git add file &&
+	test_tick &&
+	git commit -m initial &&
+	test_tick &&
+	git clone . "a submodule" &&
+	cat >.gitmodules <<EOF &&
+[submodule "a submodule"]
+        path = "a submodule"
+        url = "./a submodule"
+EOF
+	git add "a submodule" .gitmodules &&
+	git commit -m "a submodule"
+
+'
+
+test_expect_success 'Cloning repo and updating submodules using file:// URL' '
+
+	git clone "file://$TRASH_DIR" clone &&
+	cd clone &&
+	git submodule update --init &&
+	test -d "a submodule/.git"
+
+'
+
+test_expect_success 'Cloning repo and updating submodules using local path' '
+
+	rm -rf clone &&
+	git clone "$TRASH_DIR" clone &&
+	cd clone &&
+	git submodule update --init &&
+	test -d "a submodule/.git"
+
+'
+
+test_done


-- 
Johan Herland, <johan@herland.net>
www.herland.net

  reply	other threads:[~2008-08-28 23:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-27 12:00 Relative submodule URLs vs. clone URL DWIMming Johan Herland
2008-08-28 14:50 ` Mark Levedahl
2008-08-28 23:01   ` Johan Herland [this message]
2008-08-30 22:27     ` Junio C Hamano
2008-08-30 23:23       ` Johan Herland
2008-08-30 23:45         ` Junio C Hamano
2008-09-01 19:07           ` [PATCH] Bring local clone's origin URL in line with that of a remote clone Johan Herland
2008-09-02  7:23             ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200808290101.20048.johan@herland.net \
    --to=johan@herland.net \
    --cc=git@vger.kernel.org \
    --cc=mlevedahl@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).