[PATCH] Bring local clone's origin URL in line with that of a remote clone
- From
Johan Herland <johan@herland.net>
- Date
- Sep 1, 2008, 19:07 UTC
- Message-ID
- <200809012107.34020.johan@herland.net>
- In-Reply-To
- <7vabeuf4oj.fsf@gitster.siamese.dyndns.org>
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 <johan@herland.net> ---
On Sunday 31 August 2008, Junio C Hamano wrote:
Show 18 quoted lines
> Johan Herland <johan@herland.net> 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.
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