{"thread":{"id":"5920","subject":"[PATCH] clone: the given repository dir should be relative to $PWD","startedAt":"2006-10-14T12:02:51Z","lastAt":"2006-10-15T03:09:20Z","messageCount":3,"participants":["Yasushi SHOJI","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"28759","messageId":"87ac3zqebs.wl@mail2.atmark-techno.com","threadId":"5920","inReplyTo":null,"subject":"[PATCH] clone: the given repository dir should be relative to $PWD","fromName":"Yasushi SHOJI","fromEmail":"yashi@atmark-techno.com","sentAt":"2006-10-14T12:02:51Z","receivedAt":"2006-10-14T12:02:51Z","isPatch":true,"sender":{"key":"yashi@atmark-techno.com","avatar":"https://gravatar.com/avatar/4817e8703ac4379935834d87453faa9d0c94b9dc19d83fcc54c67875eb133e59?d=mp&s=160"},"body":"the repository argument for git-clone should be relative to $PWD\ninstead of the given target directory. The old behavior gave us\nsurprising success and you need a few minute to know why it worked.\n\nGIT_DIR is already exported so no need to cd into $D. And this makes\n$PWD for git-fetch-pack, which is the actual command to take the given\nrepository dir, the same as git-clone.\n\nSigned-off-by: Yasushi SHOJI \n---\n\nWhile I'm not sure this is a feature we rely on or not, and I don't\nwant to change the way people work, IMHO the old behaviour isn't\nappropriate for such higher level porcelain.\n\nThe patch should be for post 1.4.3.\n\n\n git-clone.sh | 2 +-\n t/t5600-clone-fail-cleanup.sh | 6 ++++++\n 2 files changed, 7 insertions(+), 1 deletions(-)\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 3998c55..bf54a11 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -312,7 +312,7 @@ yes,yes)\n \t\tfi\n \t\t;;\n \t*)\n-\t\tcd \"$D\" && case \"$upload_pack\" in\n+\t\tcase \"$upload_pack\" in\n \t\t'') git-fetch-pack --all -k $quiet \"$repo\" ;;\n \t\t*) git-fetch-pack --all -k $quiet \"$upload_pack\" \"$repo\" ;;\n \t\tesac >\"$GIT_DIR/CLONE_HEAD\" || {\ndiff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh\nindex 0c6a363..041be04 100755\n--- a/t/t5600-clone-fail-cleanup.sh\n+++ b/t/t5600-clone-fail-cleanup.sh\n@@ -25,6 +25,12 @@ test_create_repo foo\n # clone doesn't like it if there is no HEAD. Is that a bug?\n (cd foo && touch file && git add file && git commit -m 'add file' >/dev/null 2>&1)\n \n+# source repository given to git-clone should be relative to the\n+# current path not to the target dir\n+test_expect_failure \\\n+ 'clone of non-existent (relative to $PWD) source should fail' \\\n+ 'git-clone ../foo baz'\n+\n test_expect_success \\\n 'clone should work now that source exists' \\\n 'git-clone foo bar'\n-- \n1.4.2.3\n"},{"id":"28785","messageId":"7v7iz274zy.fsf@assigned-by-dhcp.cox.net","threadId":"5920","inReplyTo":"87ac3zqebs.wl@mail2.atmark-techno.com","subject":"Re: [PATCH] clone: the given repository dir should be relative to $PWD","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-15T01:16:33Z","receivedAt":"2006-10-15T01:16:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yasushi SHOJI writes:\n\n> the repository argument for git-clone should be relative to $PWD\n> instead of the given target directory. The old behavior gave us\n> surprising success and you need a few minute to know why it worked.\n>\n> GIT_DIR is already exported so no need to cd into $D. And this makes\n> $PWD for git-fetch-pack, which is the actual command to take the given\n> repository dir, the same as git-clone.\n>\n> Signed-off-by: Yasushi SHOJI \n> ---\n>\n> While I'm not sure this is a feature we rely on or not, and I don't\n> want to change the way people work, IMHO the old behaviour isn't\n> appropriate for such higher level porcelain.\n>\n> The patch should be for post 1.4.3.\n\nWell spotted. I am fairly sure that this \"clone from repository\nrelative to the target\" is not intended behaviour. I'd say we\nshould fix this before 1.4.3.\n\n... or are there any valid reason to keep the current behaviour\nthat I missed?\n"},{"id":"28789","messageId":"878xjiqnq7.wl@mail2.atmark-techno.com","threadId":"5920","inReplyTo":"7v7iz274zy.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] clone: the given repository dir should be relative to $PWD","fromName":"Yasushi SHOJI","fromEmail":"yashi@atmark-techno.com","sentAt":"2006-10-15T03:09:20Z","receivedAt":"2006-10-15T03:09:20Z","isPatch":true,"sender":{"key":"yashi@atmark-techno.com","avatar":"https://gravatar.com/avatar/4817e8703ac4379935834d87453faa9d0c94b9dc19d83fcc54c67875eb133e59?d=mp&s=160"},"body":"At Sat, 14 Oct 2006 18:16:33 -0700,\nJunio C Hamano wrote:\n> \n> Yasushi SHOJI writes:\n> \n> > the repository argument for git-clone should be relative to $PWD\n> > instead of the given target directory. The old behavior gave us\n> > surprising success and you need a few minute to know why it worked.\n> >\n> > GIT_DIR is already exported so no need to cd into $D. And this makes\n> > $PWD for git-fetch-pack, which is the actual command to take the given\n> > repository dir, the same as git-clone.\n> >\n> > Signed-off-by: Yasushi SHOJI \n> > ---\n> >\n> > While I'm not sure this is a feature we rely on or not, and I don't\n> > want to change the way people work, IMHO the old behaviour isn't\n> > appropriate for such higher level porcelain.\n> >\n> > The patch should be for post 1.4.3.\n> \n> Well spotted. I am fairly sure that this \"clone from repository\n> relative to the target\" is not intended behaviour. I'd say we\n> should fix this before 1.4.3.\n\nOK. if the behavior isn't intended and there ain't much user for it,\nI don't have any reason not to. my last sentence was more like a\nquestion to you rather than my statement.\n\nlet's fix it before 1.4.3.\n\n> ... or are there any valid reason to keep the current behaviour\n> that I missed?\n\nI don't think so. I personally consider the behavior a bug. I just\nthought that we don't want to have user saying \"hey, v1.4.3 doesn't\nwork any more!\" report, given that we are already in -rc2.\n-- \n yashi\n"}]}