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

Timo Hirvonen [off-list ref] 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?

Hi,

On Wed, 19 Oct 2005, Junio C Hamano wrote:

What do people on the list think?

For projects with a long history, it might make sense to do it 
unconditionally, but for young projects, the packs would be very small and 
inefficient.

However, I cannot think of other use cases where "--keep" would not make 
sense, and since projects tend to get a long history, maybe it would be 
good to introduce a "--nokeep" to git-clone.

JM2C,
Dscho

On Wed, 19 Oct 2005, Junio C Hamano wrote:

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

No, I think the unconditional --keep is fine for clone.

What to do about incremental pulls is not as clear, but I think the clone 
case is pretty much obvious these days.

The main reason for unpacking was that packs used to be "strange". These 
days, packs are arguably the _common_ thing.

Now, having tons and tons of small packs is probably worse than having 
tons and tons of individual files, but if people get used to doing 
occasional full repacks, that doesn't matter.

		Linus