patchgit-clone: don't unpack objects

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

Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>

---

 git-clone.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

applies-to: 984b42b74993da2be26cd2b50ac1d3e74b0c4cd5 63a266005116dd914c85b4c5f97d0e628f0b37ec

Timo Hirvonen <tihirvon@gmail.com> writes:

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:

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:

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

Linus Torvalds <torvalds@osdl.org> writes:

OK, that makes sense. 

I'd move this 'unconditional keep' to clone-pack. The --keep flag becomes a no-op.