clone: the given repository dir should be relative to $PWD
PATCH 1/1 clone: the given repository dir should be relative to $PWD
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.
---
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(-)
git-clone.sh +1 -1
@@ -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" || {
t/t5600-clone-fail-cleanup.sh +6 -0
@@ -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'
Signature · 1 line
1.4.2.3
Quoted 8 lines · 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_DIRis 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.
Quoted 8 lines
Signed-off-by Yasushi SHOJI <[email protected]>---
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?
At Sat, 14 Oct 2006 18:16:33 -0700,
Quoted 18 lines · Junio C Hamano
Quoted 15 lines · 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_DIRis 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 <[email protected]>---
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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 2 lines
... 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.
Signature · 1 line
yashi