quick bare clones taking longer?

quick bare clones taking longer?

[David Miller]

master.kernel.org just upgraded to git-1.5.1.4 and I notice
that doing something like this:

	git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git

is no longer an instantaneous operation, it seems to be doing a lot
of stuff now:

Initialized empty Git repository in /home/davem/git/test-2.6.git/
remote: Generating pack...
remote: Done counting 480025 objects.
remote: Deltifying 480025 objects.
remote:  100% (480025/480025) done
Indexing 480025 objects.
remote: Total 480025 (delta 385878), reused 473265 (delta 379369)
 100% (480025/480025) done
Resolving 385878 deltas.
 100% (385878/385878) done

Is there a new way to get a quick clone?

Thanks!

Re: quick bare clones taking longer?

[Johannes Schindelin]

Hi,

On Wed, 9 May 2007, David Miller wrote:

> master.kernel.org just upgraded to git-1.5.1.4 and I notice
> that doing something like this:
> 
> 	git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git
> 
> is no longer an instantaneous operation, it seems to be doing a lot
> of stuff now:
> 
> Initialized empty Git repository in /home/davem/git/test-2.6.git/
> remote: Generating pack...
> remote: Done counting 480025 objects.
> remote: Deltifying 480025 objects.
> remote:  100% (480025/480025) done
> Indexing 480025 objects.
> remote: Total 480025 (delta 385878), reused 473265 (delta 379369)
>  100% (480025/480025) done
> Resolving 385878 deltas.
>  100% (385878/385878) done
> 
> Is there a new way to get a quick clone?

I just checked out 1.5.1.4, built it, and cannot reproduce this behaviour. 
It's as fast as ever.

Ciao,
Dscho

Re: quick bare clones taking longer?

[Junio C Hamano]

David Miller <davem@davemloft.net> writes:

> master.kernel.org just upgraded to git-1.5.1.4 and I notice
> that doing something like this:
>
> 	git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git
>
> is no longer an instantaneous operation, it seems to be doing a lot
> of stuff now:
>
> Initialized empty Git repository in /home/davem/git/test-2.6.git/
> remote: Generating pack...
> remote: Done counting 480025 objects.
> remote: Deltifying 480025 objects.
> remote:  100% (480025/480025) done
> Indexing 480025 objects.
> remote: Total 480025 (delta 385878), reused 473265 (delta 379369)
>  100% (480025/480025) done
> Resolving 385878 deltas.
>  100% (385878/385878) done
>
> Is there a new way to get a quick clone?

There is something very wrong.  "-l -s" should never go to the
"remote: Generating pack..." codepath.  Is that reproducible?
Could you try "sh -x git-clone" it?

Re: quick bare clones taking longer?

[David Miller]

From: Junio C Hamano <junkio@cox.net>
Date: Wed, 09 May 2007 08:41:20 -0700

> There is something very wrong.  "-l -s" should never go to the
> "remote: Generating pack..." codepath.  Is that reproducible?

Every single time on master.kernel.org

> Could you try "sh -x git-clone" it?

Sure:

+ unset CDPATH
+ '[' -n '' ']'
+ quiet=
+ local=no
+ use_local=no
+ local_shared=no
+ unset template
+ no_checkout=
+ upload_pack=
+ bare=
+ reference=
+ origin=
+ origin_override=
+ use_separate_remote=t
+ depth=
+ no_progress=
+ test -t 1
+ case "$#,$1" in
+ bare=yes
+ shift
+ case "$#,$1" in
+ no_checkout=yes
+ shift
+ case "$#,$1" in
+ use_local=yes
+ shift
+ case "$#,$1" in
+ local_shared=yes
+ use_local=yes
+ shift
+ case "$#,$1" in
+ break
+ repo=../torvalds/linux-2.6.git
+ test -n ../torvalds/linux-2.6.git
+ test yes = yes
+ test yes = ''
+ no_checkout=yes
+ use_separate_remote=
+ test -z ''
+ origin=origin
++ get_repo_base ../torvalds/linux-2.6.git
+ base=
+ dir=test-2.6.git
+ '[' -z test-2.6.git ']'
+ '[' -e test-2.6.git ']'
+ mkdir -p test-2.6.git
++ cd test-2.6.git
++ pwd
+ D=/home/davem/git/test-2.6.git
+ trap 'err=$?; cd ..; rm -rf "$D"; exit $err' 0
+ case "$bare" in
+ GIT_DIR=/home/davem/git/test-2.6.git
+ export GIT_DIR
+ git-init
Initialized empty Git repository in /home/davem/git/test-2.6.git/
+ test -n ''
+ rm -f /home/davem/git/test-2.6.git/CLONE_HEAD
+ case "$local,$use_local" in
+ case "$repo" in
+ case "$upload_pack" in
+ git-fetch-pack --all -k ../torvalds/linux-2.6.git
remote: Generating pack...

etc.

Oh, /home/davem/git is a soft symlink to
/pub/scm/linux/kernel/git/davem, maybe that is confusing
git to make it think the repo is not local.

Re: quick bare clones taking longer?

[Junio C Hamano]

David Miller <davem@davemloft.net> writes:

> From: Junio C Hamano <junkio@cox.net>
> Date: Wed, 09 May 2007 08:41:20 -0700
>
>> There is something very wrong.  "-l -s" should never go to the
>> "remote: Generating pack..." codepath.  Is that reproducible?
>
> Every single time on master.kernel.org
>
>> Could you try "sh -x git-clone" it?
>
> Sure:
>
> + unset CDPATH
> + '[' -n '' ']'
> + quiet=
> + local=no
> + use_local=no
> + local_shared=no
> + unset template
> + no_checkout=
> + upload_pack=
> + bare=
> + reference=
> + origin=
> + origin_override=
> + use_separate_remote=t
> + depth=
> + no_progress=
> + test -t 1
> + case "$#,$1" in
> + bare=yes
> + shift
> + case "$#,$1" in
> + no_checkout=yes
> + shift
> + case "$#,$1" in
> + use_local=yes
> + shift
> + case "$#,$1" in
> + local_shared=yes
> + use_local=yes
> + shift
> + case "$#,$1" in
> + break
> + repo=../torvalds/linux-2.6.git
> + test -n ../torvalds/linux-2.6.git
> + test yes = yes
> + test yes = ''
> + no_checkout=yes
> + use_separate_remote=
> + test -z ''
> + origin=origin
> ++ get_repo_base ../torvalds/linux-2.6.git
> + base=

This part puzzles me.  The only way I could reproduce this was:

$ ls -F victim victim.git
ls: victim: No such file or directory
victim.git:
./   HEAD	config	 description	       hooks/  lost-found/  refs/
../  branches/	config~  gitcvs.master.sqlite  info/   objects/     remotes/
$ mkdir j
$ cd j
$ git clone --bare -l -s -n ../victim new.git

That is, I did not have ../victim but I did have ../victim.git/
repository, and I gave the former to "git clone".

But that suggests that you do not have ../torvalds/linux-2.6.git
directory but instead have ../torvalds/linux-2.6.git.git/ which
sound a bit insane.

Puzzled...

Re: quick bare clones taking longer?

[David Miller]

From: Junio C Hamano <junkio@cox.net>
Date: Wed, 09 May 2007 14:48:38 -0700

> > + no_checkout=yes
> > + use_separate_remote=
> > + test -z ''
> > + origin=origin
> > ++ get_repo_base ../torvalds/linux-2.6.git
> > + base=
> 
> This part puzzles me.  The only way I could reproduce this was:
> 
> $ ls -F victim victim.git
> ls: victim: No such file or directory
> victim.git:
> ./   HEAD	config	 description	       hooks/  lost-found/  refs/
> ../  branches/	config~  gitcvs.master.sqlite  info/   objects/     remotes/
> $ mkdir j
> $ cd j
> $ git clone --bare -l -s -n ../victim new.git
> 
> That is, I did not have ../victim but I did have ../victim.git/
> repository, and I gave the former to "git clone".
> 
> But that suggests that you do not have ../torvalds/linux-2.6.git
> directory but instead have ../torvalds/linux-2.6.git.git/ which
> sound a bit insane.
> 
> Puzzled...

This deeply puzzles me too.

I'm just not going to go into my git directory using that
symlink in my home directory any more. :-)

Re: quick bare clones taking longer?

[Junio C Hamano]

David Miller <davem@davemloft.net> writes:

> From: Junio C Hamano <junkio@cox.net>
> Date: Wed, 09 May 2007 14:48:38 -0700
>
>> > + no_checkout=yes
>> > + use_separate_remote=
>> > + test -z ''
>> > + origin=origin
>> > ++ get_repo_base ../torvalds/linux-2.6.git
>> > + base=
>> 
>> This part puzzles me.  The only way I could reproduce this was:
>> 
>> $ ls -F victim victim.git
>> ls: victim: No such file or directory
>> victim.git:
>> ./   HEAD	config	 description	       hooks/  lost-found/  refs/
>> ../  branches/	config~  gitcvs.master.sqlite  info/   objects/     remotes/
>> $ mkdir j
>> $ cd j
>> $ git clone --bare -l -s -n ../victim new.git
>> 
>> That is, I did not have ../victim but I did have ../victim.git/
>> repository, and I gave the former to "git clone".
>> 
>> But that suggests that you do not have ../torvalds/linux-2.6.git
>> directory but instead have ../torvalds/linux-2.6.git.git/ which
>> sound a bit insane.
>> 
>> Puzzled...
>
> This deeply puzzles me too.
>
> I'm just not going to go into my git directory using that
> symlink in my home directory any more. :-)

Ahhh, symlink!

get_repo_base does this:

        get_repo_base() {
                (cd "$1" && (cd .git ; pwd)) 2> /dev/null
        }

and is used like this:

        # Turn the source into an absolute path if
        # it is local
        if base=$(get_repo_base "$repo"); then
                repo="$base"
                local=yes
        fi

That is, get_repo_base does:

 * first try to cd to ../torvalds/linux-2.6.git; if it fails
   then give up.

 * then further cd down to .git if we can but do not worry about
   it if we can't.  Report where we are and succeed.

If the above "fails", the caller considers the cloned-from
repository a non-local one, and turns off -l -s optimization.

The above sequence is called before we create the new directory
and chdir to it.  Maybe pwd has funny behaviour (e.g. $PWD) and
we need to explicitly say /bin/pwd or somesuch...

Re: quick bare clones taking longer?

[David Miller]

From: Junio C Hamano <junkio@cox.net>
Date: Wed, 09 May 2007 15:59:23 -0700

> The above sequence is called before we create the new directory
> and chdir to it.  Maybe pwd has funny behaviour (e.g. $PWD) and
> we need to explicitly say /bin/pwd or somesuch...

Indeed:

[davem@hera ~]$ pwd
/home/davem
[davem@hera ~]$ cd git
[davem@hera git]$ pwd
/home/davem/git
[davem@hera git]$ /bin/pwd
/home/ftp/pub/scm/linux/kernel/git/davem
[davem@hera git]$ 

Re: quick bare clones taking longer?

[Junio C Hamano]

David Miller <davem@davemloft.net> writes:

> From: Junio C Hamano <junkio@cox.net>
> Date: Wed, 09 May 2007 15:59:23 -0700
>
>> The above sequence is called before we create the new directory
>> and chdir to it.  Maybe pwd has funny behaviour (e.g. $PWD) and
>> we need to explicitly say /bin/pwd or somesuch...
>
> Indeed:
>
> [davem@hera ~]$ pwd
> /home/davem
> [davem@hera ~]$ cd git
> [davem@hera git]$ pwd
> /home/davem/git
> [davem@hera git]$ /bin/pwd
> /home/ftp/pub/scm/linux/kernel/git/davem
> [davem@hera git]$ 

Thanks.

Re: quick bare clones taking longer?

[Junio C Hamano]

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

> David Miller <davem@davemloft.net> writes:
>
>> From: Junio C Hamano <junkio@cox.net>
>> Date: Wed, 09 May 2007 15:59:23 -0700
>>
>>> The above sequence is called before we create the new directory
>>> and chdir to it.  Maybe pwd has funny behaviour (e.g. $PWD) and
>>> we need to explicitly say /bin/pwd or somesuch...
>>
>> Indeed:
>>
>> [davem@hera ~]$ pwd
>> /home/davem
>> [davem@hera ~]$ cd git
>> [davem@hera git]$ pwd
>> /home/davem/git
>> [davem@hera git]$ /bin/pwd
>> /home/ftp/pub/scm/linux/kernel/git/davem
>> [davem@hera git]$ 
>
> Thanks.

This would fix it, but I find this kind of ugly.

-- >8 --
git-clone: don't get fooled by $PWD

If you have /home/me/git symlink pointing at /pub/git/mine,
trying to clone from /pub/git/his/ using relative path would not
work as expected:

	$ cd /home/me
        $ cd git
        $ ls ../
        his    mine
        $ git clone -l -s -n ../his/stuff.git

This is because "cd ../his/stuff.git" done inside git-clone to
check if the repository is local is confused by $PWD, which is
set to /home/me, and tries to go to /home/his/stuff.git which is
different from /pub/git/his/stuff.git.

We could probably say "set -P" (or "cd -P") instead, if we know
the shell is POSIX, but the way the patch is coded is probably
more portable.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

diff --git a/git-clone.sh b/git-clone.sh
index cad5c0c..c5852a2 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -18,7 +18,14 @@ usage() {
 }
 
 get_repo_base() {
-	(cd "$1" && (cd .git ; pwd)) 2> /dev/null
+	(
+		cd "`/bin/pwd`" &&
+		cd "$1" &&
+		(
+			cd .git
+			pwd
+		)
+	) 2>/dev/null
 }
 
 if [ -n "$GIT_SSL_NO_VERIFY" ]; then

Re: quick bare clones taking longer?

[Junio C Hamano]

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

> Junio C Hamano <junkio@cox.net> writes:
>
>> David Miller <davem@davemloft.net> writes:
>>
>>> From: Junio C Hamano <junkio@cox.net>
>>> Date: Wed, 09 May 2007 15:59:23 -0700
>>>
>>>> The above sequence is called before we create the new directory
>>>> and chdir to it.  Maybe pwd has funny behaviour (e.g. $PWD) and
>>>> we need to explicitly say /bin/pwd or somesuch...
>>>
>>> Indeed:
>>>
>>> [davem@hera ~]$ pwd
>>> /home/davem
>>> [davem@hera ~]$ cd git
>>> [davem@hera git]$ pwd
>>> /home/davem/git
>>> [davem@hera git]$ /bin/pwd
>>> /home/ftp/pub/scm/linux/kernel/git/davem
>>> [davem@hera git]$ 
>>
>> Thanks.
>
> This would fix it, but I find this kind of ugly.

Side note.  Earlier you said:

   master.kernel.org just upgraded to git-1.5.1.4 and I notice
   that doing something like this:

           git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git

   is no longer an instantaneous operation, it seems to be doing a lot
   of stuff now:

But I do not see any difference between v1.5.1.3 and v1.5.1.4 in
this area.  In fact, that get_repo_base() shell function has not
changed since v0.99.

Re: quick bare clones taking longer?

[David Miller]

From: Junio C Hamano <junkio@cox.net>
Date: Wed, 09 May 2007 17:27:41 -0700

> Side note.  Earlier you said:
> 
>    master.kernel.org just upgraded to git-1.5.1.4 and I notice
>    that doing something like this:
> 
>            git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git
> 
>    is no longer an instantaneous operation, it seems to be doing a lot
>    of stuff now:
> 
> But I do not see any difference between v1.5.1.3 and v1.5.1.4 in
> this area.  In fact, that get_repo_base() shell function has not
> changed since v0.99.

Correct.  I happened to create and start using that symlink
around the same time they upgraded, that's why I made that
(false) connection.

There is no connection between git version and this problem, it's just
the symlink thing.

Re: quick bare clones taking longer?

[Matthieu Moy]

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

>  get_repo_base() {
> -	(cd "$1" && (cd .git ; pwd)) 2> /dev/null
> +	(
> +		cd "`/bin/pwd`" &&
> +		cd "$1" &&
> +		(
> +			cd .git
> +			pwd
> +		)
> +	) 2>/dev/null
>  }

Will this work on windows?

-- 
Matthieu

Re: quick bare clones taking longer?

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> Junio C Hamano <junkio@cox.net> writes:
>
>>  get_repo_base() {
>> -	(cd "$1" && (cd .git ; pwd)) 2> /dev/null
>> +	(
>> +		cd "`/bin/pwd`" &&
>> +		cd "$1" &&
>> +		(
>> +			cd .git
>> +			pwd
>> +		)
>> +	) 2>/dev/null
>>  }
>
> Will this work on windows?

Is that a serious question?

If so, my answer is "I do not know, but the update is not any
more complex than the existing code -- both are perfectly fine
POSIX shell".  Besides, if there are enough users who care about
Windows, there must be some competent ones among them, and we
will hear from them soon enough with an improvement patch.

If not, welcome to my killfile ;-).

NB.  No, the last one is not serious.  I do not have a
killfile.

Re: quick bare clones taking longer?

[Matthieu Moy]

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

> Is that a serious question?

It is. I have to admit that my knowledge about POSIX kind of things on
windows approaches zero, but a hardcoded /bin/something path sounds
suspicious to me.

Nothing more, nothing less in my question.

-- 
Matthieu

Re: quick bare clones taking longer?

[Brian Gernhardt]

On May 10, 2007, at 4:55 AM, Matthieu Moy wrote:

> Junio C Hamano <junkio@cox.net> writes:
>
>> Is that a serious question?
>
> It is. I have to admit that my knowledge about POSIX kind of things on
> windows approaches zero, but a hardcoded /bin/something path sounds
> suspicious to me.

I think every POSIX environment provides _something_ for /bin and / 
usr/bin.  There are too many scripts that start "#!/bin/bash" or "#!/ 
usr/bin/env interpreter" for it not to.  And to be POSIX, the basic  
utilities (like pwd and env) should be in there.  Someday Git may  
work on Windows without a funny (for MS) environment.  But that day  
is not today.  Tomorrow doesn't look too good either.  ;-)

~~ Brian

Win32 version, was Re: quick bare clones taking longer?

[Johannes Schindelin]

Hi,

On Thu, 10 May 2007, Brian Gernhardt wrote:

> Someday Git may work on Windows without a funny (for MS) environment.  
> But that day is not today.  Tomorrow doesn't look too good either.  ;-)

It sure sounds like you would like that day rather sooner than later. In 
related news, that day will be sooner rather than later, if people who 
actually care deeply about this _do_ something about it.

Hth,
Dscho

Re: Win32 version, was Re: quick bare clones taking longer?

[Brian Gernhardt]

On May 12, 2007, at 11:25 AM, Johannes Schindelin wrote:

> On Thu, 10 May 2007, Brian Gernhardt wrote:
>
>> Someday Git may work on Windows without a funny (for MS) environment.
>> But that day is not today.  Tomorrow doesn't look too good  
>> either.  ;-)
>
> It sure sounds like you would like that day rather sooner than  
> later. In
> related news, that day will be sooner rather than later, if people who
> actually care deeply about this _do_ something about it.

Actually, at the moment, my only Windows environment is inside a VM  
box on my Mac.  So as long as it works on my Mac, I don't care how  
long it takes.  And I have neither the time nor build environment to  
try to fix it.  If that changes, I'll produce patches like a good  
code monkey.

~~ Brian

Re: quick bare clones taking longer?

[Johannes Sixt]

Matthieu Moy wrote:
> 
> Junio C Hamano <junkio@cox.net> writes:
> 
> >  get_repo_base() {
> > -     (cd "$1" && (cd .git ; pwd)) 2> /dev/null
> > +     (
> > +             cd "`/bin/pwd`" &&
> > +             cd "$1" &&
> > +             (
> > +                     cd .git
> > +                     pwd
> > +             )
> > +     ) 2>/dev/null
> >  }
> 
> Will this work on windows?

Yes. As does the alternative that uses cd -P. MinGW uses bash (3.1
here).

-- Hannes

Re: quick bare clones taking longer?

[Dan Nicholson]

Johannes Sixt <J.Sixt <at> eudaptics.com> writes:
> 
> Matthieu Moy wrote:
> > 
> > Junio C Hamano <junkio <at> cox.net> writes:
> > 
> > >  get_repo_base() {
> > > -     (cd "$1" && (cd .git ; pwd)) 2> /dev/null
> > > +     (
> > > +             cd "`/bin/pwd`" &&
> > > +             cd "$1" &&
> > > +             (
> > > +                     cd .git
> > > +                     pwd
> > > +             )
> > > +     ) 2>/dev/null
> > >  }
> > 
> > Will this work on windows?
> 
> Yes. As does the alternative that uses cd -P. MinGW uses bash (3.1
> here).

In fact, all POSIX shells should support `cd -P' according to the spec, so it
should probably just be used directly instead of hoping that /bin/pwd exists.

(cd -P "$1" && (cd .git ; pwd)) 2>/dev/null

http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html

--
Dan

Re: quick bare clones taking longer?

[Junio C Hamano]

Dan Nicholson <dbn.lists@gmail.com> writes:

> In fact, all POSIX shells should support `cd -P' according to the spec, so it
> should probably just be used directly instead of hoping that /bin/pwd exists.
>
> (cd -P "$1" && (cd .git ; pwd)) 2>/dev/null
>
> http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html

Yes but no ;-).  I've said this a few times on the list in the
past, but I'll repeat it again for new people.

We reject something whose portability in question by saying
"It's not _even in_ POSIX".  We on the other hand try to refrain
from saying "POSIX says you are supposed to have it, so screw
people that are not fully POSIX".

Re: quick bare clones taking longer?

[Dan Nicholson]

On 5/10/07, Junio C Hamano <junkio@cox.net> wrote:
> Dan Nicholson <dbn.lists@gmail.com> writes:
>
> > In fact, all POSIX shells should support `cd -P' according to the spec, so it
> > should probably just be used directly instead of hoping that /bin/pwd exists.
> >
> > (cd -P "$1" && (cd .git ; pwd)) 2>/dev/null
> >
> > http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html
>
> Yes but no ;-).  I've said this a few times on the list in the
> past, but I'll repeat it again for new people.
>
> We reject something whose portability in question by saying
> "It's not _even in_ POSIX".  We on the other hand try to refrain
> from saying "POSIX says you are supposed to have it, so screw
> people that are not fully POSIX".

Yes, I suppose. At the same time, git already implicitly requires more
than, say, a Bourne shell. Functions, $( ) command substitution, ${}
parameter expansion, $(( )) arithmetic expansion, etc. These are all
standard in a POSIX shell, but may or may not exist in other shell
variants.

--
Dan

Re: quick bare clones taking longer?

[Junio C Hamano]

"Dan Nicholson" <dbn.lists@gmail.com> writes:

> On 5/10/07, Junio C Hamano <junkio@cox.net> wrote:
> ...
>> We reject something whose portability is in question by saying
>> "It's not _even in_ POSIX".  We on the other hand try to refrain
>> from saying "POSIX says you are supposed to have it, so screw
>> people that are not fully POSIX".
>
> Yes, I suppose. At the same time, git already implicitly requires more
> than, say, a Bourne shell.

Yes, and the line is fuzzy and case by case.  I am playing it
safe as we are in pre-release freeze, also I condider /bin/pwd
much more universally available than "cd -P".

Re: quick bare clones taking longer?

[Andy Whitcroft]

Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> 
>> David Miller <davem@davemloft.net> writes:
>>
>>> From: Junio C Hamano <junkio@cox.net>
>>> Date: Wed, 09 May 2007 15:59:23 -0700
>>>
>>>> The above sequence is called before we create the new directory
>>>> and chdir to it.  Maybe pwd has funny behaviour (e.g. $PWD) and
>>>> we need to explicitly say /bin/pwd or somesuch...
>>> Indeed:
>>>
>>> [davem@hera ~]$ pwd
>>> /home/davem
>>> [davem@hera ~]$ cd git
>>> [davem@hera git]$ pwd
>>> /home/davem/git
>>> [davem@hera git]$ /bin/pwd
>>> /home/ftp/pub/scm/linux/kernel/git/davem
>>> [davem@hera git]$ 
>> Thanks.
> 
> This would fix it, but I find this kind of ugly.
> 
> -- >8 --
> git-clone: don't get fooled by $PWD
> 
> If you have /home/me/git symlink pointing at /pub/git/mine,
> trying to clone from /pub/git/his/ using relative path would not
> work as expected:
> 
> 	$ cd /home/me
>         $ cd git
>         $ ls ../
>         his    mine
>         $ git clone -l -s -n ../his/stuff.git
> 
> This is because "cd ../his/stuff.git" done inside git-clone to
> check if the repository is local is confused by $PWD, which is
> set to /home/me, and tries to go to /home/his/stuff.git which is
> different from /pub/git/his/stuff.git.
> 
> We could probably say "set -P" (or "cd -P") instead, if we know
> the shell is POSIX, but the way the patch is coded is probably
> more portable.
> 
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
> 
> diff --git a/git-clone.sh b/git-clone.sh
> index cad5c0c..c5852a2 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -18,7 +18,14 @@ usage() {
>  }
>  
>  get_repo_base() {
> -	(cd "$1" && (cd .git ; pwd)) 2> /dev/null
> +	(
> +		cd "`/bin/pwd`" &&
> +		cd "$1" &&
> +		(
> +			cd .git
> +			pwd
> +		)
> +	) 2>/dev/null
>  }
>  
>  if [ -n "$GIT_SSL_NO_VERIFY" ]; then

That is pretty much how I have seen this solved in the past.  One thing
while you are playing with this code.  There seems to be an extra
sub-shell in there unnecesarily and the error redirection seems a little
aggressive?

This seems to be semantically equivalent:

get_repo_base() {
	(
		cd "`/bin/pwd`" &&
		cd "$1" &&
		{
			cd .git 2>/dev/null
			pwd
		}
	)
}

-apw