Re: [PATCH] git-clone: don't unpack objects

From: Junio C Hamano <junkio@cox.net>
Date: Oct 19, 2005, 20:09 UTC
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?