[PATCH] clone: the given repository dir should be relative to $PWD

[PATCH] clone: the given repository dir should be relative to $PWD

[Yasushi SHOJI]

the repository argument for git-clone should be relative to $PWD
instead of the given target directory.  The old behavior gave us
surprising success and you need a few minute to know why it worked.

GIT_DIR is already exported so no need to cd into $D. And this makes
$PWD for git-fetch-pack, which is the actual command to take the given
repository dir, the same as git-clone.

Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---

While I'm not sure this is a feature we rely on or not, and I don't
want to change the way people work, IMHO the old behaviour isn't
appropriate for such higher level porcelain.

The patch should be for post 1.4.3.


 git-clone.sh                  |    2 +-
 t/t5600-clone-fail-cleanup.sh |    6 ++++++
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index 3998c55..bf54a11 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -312,7 +312,7 @@ yes,yes)
 		fi
 		;;
 	*)
-		cd "$D" && case "$upload_pack" in
+		case "$upload_pack" in
 		'') git-fetch-pack --all -k $quiet "$repo" ;;
 		*) git-fetch-pack --all -k $quiet "$upload_pack" "$repo" ;;
 		esac >"$GIT_DIR/CLONE_HEAD" || {
diff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh
index 0c6a363..041be04 100755
--- a/t/t5600-clone-fail-cleanup.sh
+++ b/t/t5600-clone-fail-cleanup.sh
@@ -25,6 +25,12 @@ test_create_repo foo
 # clone doesn't like it if there is no HEAD. Is that a bug?
 (cd foo && touch file && git add file && git commit -m 'add file' >/dev/null 2>&1)
 
+# source repository given to git-clone should be relative to the
+# current path not to the target dir
+test_expect_failure \
+    'clone of non-existent (relative to $PWD) source should fail' \
+    'git-clone ../foo baz'
+
 test_expect_success \
     'clone should work now that source exists' \
     'git-clone foo bar'
-- 
1.4.2.3

Re: [PATCH] clone: the given repository dir should be relative to $PWD

[Junio C Hamano]

Yasushi SHOJI <yashi@atmark-techno.com> writes:

> the repository argument for git-clone should be relative to $PWD
> instead of the given target directory.  The old behavior gave us
> surprising success and you need a few minute to know why it worked.
>
> GIT_DIR is already exported so no need to cd into $D. And this makes
> $PWD for git-fetch-pack, which is the actual command to take the given
> repository dir, the same as git-clone.
>
> Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
> ---
>
> While I'm not sure this is a feature we rely on or not, and I don't
> want to change the way people work, IMHO the old behaviour isn't
> appropriate for such higher level porcelain.
>
> The patch should be for post 1.4.3.

Well spotted.  I am fairly sure that this "clone from repository
relative to the target" is not intended behaviour.  I'd say we
should fix this before 1.4.3.

... or are there any valid reason to keep the current behaviour
that I missed?

Re: [PATCH] clone: the given repository dir should be relative to $PWD

[Yasushi SHOJI]

At Sat, 14 Oct 2006 18:16:33 -0700,
Junio C Hamano wrote:
> 
> Yasushi SHOJI <yashi@atmark-techno.com> writes:
> 
> > the repository argument for git-clone should be relative to $PWD
> > instead of the given target directory.  The old behavior gave us
> > surprising success and you need a few minute to know why it worked.
> >
> > GIT_DIR is already exported so no need to cd into $D. And this makes
> > $PWD for git-fetch-pack, which is the actual command to take the given
> > repository dir, the same as git-clone.
> >
> > Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
> > ---
> >
> > While I'm not sure this is a feature we rely on or not, and I don't
> > want to change the way people work, IMHO the old behaviour isn't
> > appropriate for such higher level porcelain.
> >
> > The patch should be for post 1.4.3.
> 
> Well spotted.  I am fairly sure that this "clone from repository
> relative to the target" is not intended behaviour.  I'd say we
> should fix this before 1.4.3.

OK.  if the behavior isn't intended and there ain't much user for it,
I don't have any reason not to. my last sentence was more like a
question to you rather than my statement.

let's fix it before 1.4.3.

> ... or are there any valid reason to keep the current behaviour
> that I missed?

I don't think so.  I personally consider the behavior a bug. I just
thought that we don't want to have user saying "hey, v1.4.3 doesn't
work any more!" report, given that we are already in -rc2.
-- 
          yashi