git-clone seems dead

Hello,

The command "git clone" doesn't work for me, and I have no idea why. What I want to do is exactly what the tutorial describes:

<cite> Again, this can all be simplified with

git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git cd my-git git checkout </cite>

See http://kernel.org/git/?p=git/git.git;a=blob;h=6e100dbb60f5756db0f453193e53c28bf947d7cc;hb=720d150c48fc35fca13c6dfb3c76d60e4ee83b87;f=Documentation/tutorial.txt#l652

The problem is reproduced by the following sequence of commands:

mkdir ~/bin wget http://kernel.org/pub/software/scm/git/git-core-0.99.6.tar.gz tar -zxf git-core-0.99.6.tar.gz cd git-core-0.99.6 make make install cd .. git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git

All commands works fine except "git clone" which prints:

<cite>
defaulting to local storage area
* git clone [-l [-s]] [-q] [-u <upload-pack>] <repo> <dir>
</cite>

and leaves my-git/.git empty. So the problem is, that I can't get "git clone" to work, and I think, I am making correct steps.

Regards,

Peter

Peter Eriksen <s022018@student.dtu.dk> writes:

Hmph. All your steps seem sane, and after removing my git installation on one of my machines I tried the exact steps as above but did not get this.

The message 'defaulting to local storage area' comes from git-init-db, and '* git clone ...' comes from usage.

    dir="$2"
    mkdir "$dir" &&
    D=$(
            (cd "$dir" && git-init-db && pwd)
    ) &&
    test -d "$D" || usage

If you had my-git directory you would get the usage but not 'defaulting...', so that is not it. The only possibility I could think of is your 'pwd' says something different than the working directory name? I am very confused..

On 20050911 (Sun) at 1204:07 -0700, Junio C Hamano wrote:

I had the same. I was using bash with CDPATH; when CDPATH is in use and you do a cd to a relative directory, bash prints the absolute pathname on stdout during the cd. So all those relative cd's in $(cd xxx && ... && pwd) in git-clone and a few other places cause bash to print the absolute path on stdout, greatly confusing the code that uses the output text that it thinks came from pwd. I have a patch to add &>/dev/null in what I think are all the right places, if you want it, but it may be easiest just to unset CDPATH and see if that fixes the trouble.

Redirect cd output to /dev/null

If someone has the CDPATH environment variable set, bash echoes the full destination path on stdout when cd is invoked with a relative target. This breaks code that uses the output of, for example, $(cd somewhere && ... && pwd). Adding &>/dev/null to the cd command corrects the breakage in a portable way.

Signed-off-by: Greg Louis <glouis@dynamicro.ca>

--- On 20050911 (Sun) at 1804:21 -0400, Greg Louis wrote:

Hunk 2 of the patch to git-clone.sh fixes the problem described by the originator of this thread (at least it does for me).

 git-bisect.sh    |    7 ++++---
 git-clone.sh     |    6 +++---
 git-ls-remote.sh |    2 +-
 git-repack.sh    |    2 +-
 4 files changed, 9 insertions(+), 8 deletions(-)

018c87b5f7e7af2ca792c3000ce3f91a02108981

I recall somebody else had trouble when we say 'cd blah' in our script and the CDPATH in the user's environment interfere and took us elsewhere.

I do not have any problem with people who have CDPATH defined as a plain shell variable (not exported) in their interactive shells, but I really do not see a point of having CDPATH as an environment variable, exported to be honored by any unsuspecting shell scripts.

Until somebody convinces me that CDPATH in the environment is a good idea, I do not have much sympathy to people with such an environment.

Junio C Hamano <junkio@cox.net> writes: ...

Point taken. I fixed my environment by making CDPATH non-exporting, and now git-clone seems to work. Thanks Greg and Junio!

Regards,

Peter

On 20050911 (Sun) at 1847:30 -0700, Junio C Hamano wrote:

Well, that's why I didn't originally bother submitting the patch -- was 
just going to use it internally.
  
I could argue that it's a relatively harmless contribution to
robustness of the git scripts, but if someone replied that total
idiot-proofing isn't a worthwhile goal for a project of this sort, I   
wouldn't necessarily disagree.

Greg Louis <glouis@dynamicro.on.ca> writes:

I have been made aware of the CDPATH issue since Carl Baldwin diagnosed it last week, but have not done anything about it because I am ambivalent about what the right thing to do is.

We could:

 (0) do nothing and let people shoot in the foot themselves.

 (1) unset CDPATH silently while we run.  Most conveniently done
     by doing so at the beginning of git-setup-sh, and scripts
     that do not use the setup script but still does "cd".

 (2) detect CDPATH in the same places as (1), complain and die.

Among these, (1) would be naturally the approach of least resistance. It would make things "just work" for everybody, and I do not have to deal with bug reports from people with a broken environment, nor have to waste time preaching why CDPATH as an environment is bad.

That, however, would guard only me without helping the world. Such a broken environment would still harm other scripts. In that sense (2) would be a better approach -- the "complain and die" step would make it explicit what we do not like about their environments. But that would put me in the position of "CDPATH considered harmful" preacher -- I do not want to waste time on defending that position every time a misguided soul wants to keep CDPATH in his environment for whatever reason. I may end up even explaining the difference between plain shell variable and environment variable depending on how misguided that soul is X-<.

And unlike (1), it would be more baggage to carry around. It's only difference between 1 line vs 3 to 4 lines of shell scripts, but 1 line just to idiot proof feels far more attractive to me than 4 lines that starts and commits me to a crusade I do not particularly care about.

Yes, I do realize that I am contradicting myself when I say (1) does not help the world but I do not particularly want to spend time and effort on helping the world anyway. If I really wanted to make the world a better place, I should do (2) and be prepared to spend some time defending that position. Otherwise I should just weasel out of the problem by doing (1), keep silent about the issue, let other people who supply scripted solution suffer and call it their problem.

I would probably end up doing (1), though.

On 20050912 (Mon) at 0529:08 -0700, Junio C Hamano wrote:

Or (2+1==3) detect CDPATH in the same places as (1), complain with a brief explanation ("don't export CDPATH; it's really only useful in interactive shells") and unset it. That way we'd educate, in a friendly way, people who thought they needed it for some reason, or who just never noticed their vendor's /etc/profile was exporting the damn thing.

My patch was about the equivalent of (1), and (1) is what I'd feel was the most that git owes its users. Option (0) could be justified on the grounds that git users are presumably developers and ought to be able to catch that sort of blunder, but the facts that you didn't originally twig to it, and that it took me a couple of hours to find it independently, suggest that that's too cavalier an attitude (neither of us being a tyro). Option (3) does qualify as excess baggage IMHO, and option (2) as a bit unhelpfully pedantic.

As would I if the decision were mine. 

(btw I'm on the list -- no Cc: needed)

Greg Louis <glouis@dynamicro.on.ca> writes:

I like your wording above, so probably that is what is going to happen. Thanks for the suggestion.

CDPATH has two problems.  1. It takes scripts to unexpected
places (somebody had CDPATH=..:../..:$HOME and the "cd" in
git-clone.sh:get_repo_base took him to $HOME/.git when he said
"clone foo bar" to clone a repository in "foo" which had
"foo/.git").  CDPATH mechanism does not implicitly give "." at
the beginning of CDPATH, which is the most irritating part.
2. the extra echo when it does its thing.

I was under the impression that the patch fixed 2. without doing anything about 1., but I may be mistaken.

Maybe. I did not trigger it and did not immediately spot what was wrong when I heard the symptom because I do not use CDPATH anywhere myself -- I am old fashioned ;-).

On 20050912 (Mon) at 1253:13 -0700, Junio C Hamano wrote:

You're very welcome.

Oh, I agree entirely that unsetting CDPATH altogether is cleaner and more complete (and much less ugly) than putting &>/dev/null all over the place. I should have said something like, "My patch is _philosophically_ about equivalent to (1)" to make it clear I was referring to the context, ie the alternative approaches you had proposed.