git-clone seems dead

git-clone seems dead

[Peter Eriksen]

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

Re: git-clone seems dead

[Junio C Hamano]

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

> 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.

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..

Re: git-clone seems dead

[Greg Louis]

On 20050911 (Sun) at 1204:07 -0700, Junio C Hamano wrote:
> Peter Eriksen <s022018@student.dtu.dk> writes:
> 
> > 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.
> 
> 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..
> 
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.

-- 
| G r e g  L o u i s         | gpg public key: 0x400B1AA86D9E3E64 |
|  http://www.bgl.nu/~glouis |   (on my website or any keyserver) |
|  http://wecanstopspam.org in signatures helps fight junk email. |

[PATCH] Redirect cd output to /dev/null, was: git-clone seems dead

[Greg Louis]

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:

> 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.

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
diff --git a/git-bisect.sh b/git-bisect.sh
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -88,7 +88,7 @@ bisect_good() {
 bisect_next_check() {
 	next_ok=no
         test -f "$GIT_DIR/refs/bisect/bad" &&
-	case "$(cd "$GIT_DIR" && echo refs/bisect/good-*)" in
+	case "$(cd "$GIT_DIR" &>/dev/null && echo refs/bisect/good-*)" in
 	refs/bisect/good-\*) ;;
 	*) next_ok=yes ;;
 	esac
@@ -112,7 +112,7 @@ bisect_next() {
 	bisect_next_check fail
 	bad=$(git-rev-parse --verify refs/bisect/bad) &&
 	good=$(git-rev-parse --sq --revs-only --not \
-		$(cd "$GIT_DIR" && ls refs/bisect/good-*)) &&
+		$(cd "$GIT_DIR" &>/dev/null  && ls refs/bisect/good-*)) &&
 	rev=$(eval "git-rev-list --bisect $good $bad") || exit
 	if [ -z "$rev" ]; then
 	    echo "$bad was both good and bad"
@@ -133,7 +133,8 @@ bisect_next() {
 
 bisect_visualize() {
 	bisect_next_check fail
-	gitk bisect/bad --not `cd "$GIT_DIR/refs" && echo bisect/good-*`
+	gitk bisect/bad --not `cd "$GIT_DIR/refs &>/dev/null" && \
+		echo bisect/good-*`
 }
 
 bisect_reset() {
diff --git a/git-clone.sh b/git-clone.sh
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -11,7 +11,7 @@ usage() {
 }
 
 get_repo_base() {
-	(cd "$1" && (cd .git ; pwd)) 2> /dev/null
+	(cd "$1" &>/dev/null && (cd .git &>/dev/null ; pwd)) 2> /dev/null
 }
 
 if [ -n "$GIT_SSL_NO_VERIFY" ]; then
@@ -89,7 +89,7 @@ fi
 dir="$2"
 mkdir "$dir" &&
 D=$(
-	(cd "$dir" && git-init-db && pwd)
+	(cd "$dir" &>/dev/null && git-init-db && pwd)
 ) &&
 test -d "$D" || usage
 
@@ -104,7 +104,7 @@ yes,yes)
 	case "$local_shared" in
 	no)
 	    # See if we can hardlink and drop "l" if not.
-	    sample_file=$(cd "$repo" && \
+	    sample_file=$(cd "$repo" &>/dev/null && \
 			  find objects -type f -print | sed -e 1q)
 
 	    # objects directory should not be empty since we are cloning!
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -48,7 +48,7 @@ http://* | https://* )
 rsync://* )
 	mkdir $tmpdir
 	rsync -rq "$peek_repo/refs" $tmpdir || exit 1
-	(cd $tmpdir && find refs -type f) |
+	(cd $tmpdir &>/dev/null && find refs -type f) |
 	while read path
 	do
 		cat "$tmpdir/$path" | tr -d '\012'
diff --git a/git-repack.sh b/git-repack.sh
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -33,7 +33,7 @@ case ",$all_into_one," in
 	pack_objects=
 	# This part is a stop-gap until we have proper pack redundancy
 	# checker.
-	existing=`cd "$PACKDIR" && \
+	existing=`cd "$PACKDIR" &>/dev/null && \
 	    find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
 	;;
 esac



-- 
| G r e g  L o u i s         | gpg public key: 0x400B1AA86D9E3E64 |
|  http://www.bgl.nu/~glouis |   (on my website or any keyserver) |
|  http://wecanstopspam.org in signatures helps fight junk email. |

Re: [PATCH] Redirect cd output to /dev/null, was: git-clone seems dead

[Junio C Hamano]

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.

Re: [PATCH] Redirect cd output to /dev/null, was: git-clone seems dead

[Peter Eriksen]

Junio C Hamano <junkio@cox.net> writes:
...
> 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.

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

Regards,

Peter

Re: [PATCH] Redirect cd output to /dev/null, was: git-clone seems dead

[Greg Louis]

On 20050911 (Sun) at 1847:30 -0700, Junio C Hamano wrote:
> I really do not see a point of having CDPATH as an            
> environment variable, exported to be honored by any unsuspecting
> shell scripts.
> 
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.

-- 
| G r e g  L o u i s         | gpg public key: 0x400B1AA86D9E3E64 |
|  http://www.bgl.nu/~glouis |   (on my website or any keyserver) |
|  http://wecanstopspam.org in signatures helps fight junk email. |

Re: [PATCH] Redirect cd output to /dev/null, was: git-clone seems dead

[Junio C Hamano]

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

> 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.

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.

Re: [PATCH] Redirect cd output to /dev/null, was: git-clone seems dead

[Greg Louis]

On 20050912 (Mon) at 0529:08 -0700, Junio C Hamano wrote:
> Greg Louis <glouis@dynamicro.on.ca> writes:
> 
> > 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.
> 
> 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.

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.

> Among these, (1) would be naturally the approach of least
> resistance.  It would make things "just work" for everybody,

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.

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

As would I if the decision were mine. 

(btw I'm on the list -- no Cc: needed)
-- 
| G r e g  L o u i s         | gpg public key: 0x400B1AA86D9E3E64 |
|  http://www.bgl.nu/~glouis |   (on my website or any keyserver) |
|  http://wecanstopspam.org in signatures helps fight junk email. |

Re: [PATCH] Redirect cd output to /dev/null, was: git-clone seems dead

[Junio C Hamano]

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

> 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.

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

> My patch was about the equivalent of (1), and (1) is what I'd feel
> was the most that git owes its users.

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.

> 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).

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 ;-).

Re: [PATCH] Redirect cd output to /dev/null, was: git-clone seems dead

[Greg Louis]

On 20050912 (Mon) at 1253:13 -0700, Junio C Hamano wrote:
> Greg Louis <glouis@dynamicro.on.ca> writes:
> 
> > 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.
> 
> I like your wording above, so probably that is what is going to
> happen.  Thanks for the suggestion.

You're very welcome.

> 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.

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.

-- 
| G r e g  L o u i s         | gpg public key: 0x400B1AA86D9E3E64 |
|  http://www.bgl.nu/~glouis |   (on my website or any keyserver) |
|  http://wecanstopspam.org in signatures helps fight junk email. |