Johan Herland [off-list ref] writes:
$ git clone /repo/foo bar
$ grep -B1 url bar/.git/config
[remote "origin"]
url = /repo/foo/.git
vs.
$ git clone file:///repo/foo bar
$ grep -B1 url bar/.git/config
[remote "origin"]
file:///home/johan/git/foo
Hmm?
If you mean "the latter lacks 'url =' and is broken", and if that is what
happens, then it needs to be fixed. But otherwise, I do not personally
find these differences interesting.
But that does not mean I'd veto if somebody else cares deeply enough and
comes up with a clean solution.
On a local clone, "git clone" would use the fully DWIMmed path as the origin
URL in the resulting repo. This was slightly inconsistent with the case of a
remote clone where the _given_ URL was used as the origin URL (because the
DWIMming was done remotely, and was therefore not available to "git clone").
This behaviour caused problems when cloning a local non-bare repo with
relative submodule URLs, because these submodule URLs would then be resolved
against the DWIMmed URL (e.g. "/repo/.git") instead of the given URL (e.g.
"/repo").
This patch teaches "git clone" to use the _given_ URL - instead of the
DWIMmed path - as the origin URL. This causes relative submodule URLs to be
resolved correctly, as long the _given_ URL indicates the correct directory
against which the submodule URLs should be resolved.
The patch also updates a testcase that contained the old-style origin URLs.
Signed-off-by: Johan Herland <redacted>
---
On Sunday 31 August 2008, Junio C Hamano wrote:
Johan Herland [off-list ref] writes:
quoted
$ git clone /repo/foo bar
$ grep -B1 url bar/.git/config
[remote "origin"]
url = /repo/foo/.git
vs.
$ git clone file:///repo/foo bar
$ grep -B1 url bar/.git/config
[remote "origin"]
file:///home/johan/git/foo
Hmm?
If you mean "the latter lacks 'url =' and is broken", and if that is what
happens, then it needs to be fixed. But otherwise, I do not personally
find these differences interesting.
Sorry, my fault (cut-n-paste error)
But that does not mean I'd veto if somebody else cares deeply enough and
comes up with a clean solution.
Is this clean enough? It passes selftests on my box, and although it
doesn't resolve all the issues I raised in this thread, it _does_ resolve
the one issue that I first bumped into, and that triggered this thread in
the first place. I expect this one issue is also the first that most other
people would bump into when working locally with relative submodule URLs.
Have fun! :)
...Johan
builtin-clone.c | 2 +-
t/t5505-remote.sh | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index c0e3086..f44ecea 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -387,7 +387,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
path = get_repo_path(repo_name, &is_bundle);
if (path)
- repo = path;
+ repo = xstrdup(make_nonrelative_path(repo_name));
else if (!strchr(repo_name, ':'))
repo = xstrdup(make_absolute_path(repo_name));
else
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index be9ee93..c449663 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -109,7 +109,7 @@ test_expect_success 'remove remote' '
cat > test/expect << EOF
* remote origin
- URL: $(pwd)/one/.git
+ URL: $(pwd)/one
Remote branch merged with 'git pull' while on branch master
master
New remote branch (next fetch will store in remotes/origin)@@ -140,7 +140,7 @@ test_expect_success 'show' '
cat > test/expect << EOF
* remote origin
- URL: $(pwd)/one/.git
+ URL: $(pwd)/one
Remote branch merged with 'git pull' while on branch master
master
Tracked remote branches@@ -169,7 +169,7 @@ test_expect_success 'prune' '
cat > test/expect << EOF
Pruning origin
-URL: $(pwd)/one/.git
+URL: $(pwd)/one
* [would prune] origin/side2
EOF
--
1.6.0.96.g2fad1
Johan Herland [off-list ref] writes:
... I expect this one issue is also the first that most other
people would bump into when working locally with relative submodule URLs.
By the way, I find your suggestion to set the canonical URL for the
toplevel repository that relative ones should base on quite reasonable.
The patch looked good. Thanks.