quick bare clones taking longer?

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

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

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

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

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

> 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]$ 

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

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

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

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

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

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

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

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

> 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