From: Junio C Hamano <junkio@cox.net>
Date: Wed, 19 Oct 2005 20:09:11 GMT
Subject: Re: [PATCH] git-clone: don't unpack objects
Message-ID: <7v4q7d5kwo.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051019154341.2aed6998.tihirvon@gmail.com>

Timo Hirvonen <tihirvon@gmail.com> writes:

> Pass --keep flag to git-clone-pack.

Hmph.  Unconditionally?

I do not personally mind this change; I even have this in my
$HOME/share/git-core/templates/config file:

        [clone]
                keeppack = 1

Are there cases where you would do 'git clone' over git native
transport and want the resulting pack expanded?

One use pattern I could think of that you may not want to have
the keeppack behaviour is when you keep multiple, related
foreign repositories.  For example, I could do this:

    cd /tarpit
    git-clone git://kernel.org/pub/scm/.../torvalds/linux-2.6.git/ 2.6

    mkdir -p $HOME/share/git-core/templates/objects/info
    cat >$HOME/share/git-core/templates/objects/info/alternates <<\EOF
    /tarpit/2.6/.git/objects
    EOF
    # disable clone.keeppack in the templates configuration as well.
    ed $HOME/share/git-core/templates/config

    cd /tarpit
    git-clone git://kernel.org/pub/scm/.../jgarzik/libata-dev.git/ ata

The new 'ata' repository created above is set up to borrow from
the cloned '2.6' repository, even before git-clone-pack is run
(thanks to the alternates in the templates).  git-clone-pack
still needs to download and unpack 100k objects, but most of
them are already available through alternates and does not hit
the disk.  It ends up leaving about 1k unpacked object files
that are unique in ata repository.  But we cannot do this if we
say --keep in git-clone unconditionally.

BTW, probably a better way to do the above example would be
(this time without funny templates trick):

    cd /tarpit
    git-clone git://kernel.org/pub/scm/.../torvalds/linux-2.6.git/ 2.6
    git-clone -l -s -n 2.6 ata

    cd ata
    mkdir .git/refs/2.6
    mv .git/refs/heads .git/refs/tags .git/refs/2.6/.
    git-fetch-pack git://kernel.org/pub/scm/.../jgarzik/libata-dev.git/ |
    while read sha1 path
    do
	case "$path" in HEAD) continue ;; esac
	mkdir -p `dirname ".git/$path"`
    	echo "$sha1" > ".git/$path"
    done
    rm -fr .git/refs/2.6

This one asks the other side to send only 6.5k objects instead
of the full cloning-and-discarding, so it achieves the same
result with a lot less burden on the network.

So in that sense, the first example that showed using --keep
does a suboptimal thing does not qualify as a counterargument to
your change, because it already is doing something suboptimal.

What do people on the list think?