Darrin Thompson <[EMAIL PROTECTED]> writes:
> 1. Pack files should reduce the number of http round trips.
> 2. What I'm seeing when I check out mainline git is the acquisition of a
> single large pack, then 600+ more recent objects. Better than before,
> but still hundreds of round trips.
I've packed the git.git repository, by the way. It has 43
unpacked objects totalling 224 kilobytes, so cloning over dumb
http should go a lot faster until we accumulate more unpacked
objects.
Some of you may have noticed that in the proposed updates queue
("pu" branch) I have a couple of commits related to pulling from
a packed dumb http server. There are two "git fetch http://"
commits to let you pull from such, and another stupid "count
objects" script that you can use to see how many unpacked
objects you have in your repository; the latter is to help
you decide when to repack.
Brave souls may want to try out the dumb http fetch. For
example, it _should_ do the right thing even if you do the
following:
$ git clone http://www.kernel.org/pub/scm/git/git.git/ newdir
$ cd newdir
$ mv .git/objects/pack/pack-* . ;# even if you unpack packs on your
$ rm -f pack-*.idx ;# end, it should do the right thing.
$ for pack in pack-*.pack; do
git-unpack-objects <$pack
rm -f "$pack"
done
$ rm -f .git/refs/heads/pu
$ git prune ;# lose objects in "pu" but still not in "master"
$ git pull origin pu
$ git ls-remote origin |
while read sha1 refname
do
case "$refname" in
refs/heads/master) echo $sha1 >".git/$refname" ;;
esac
done ;# revert master to upstream master
$ old=$(git-rev-parse master^^^^^^^^^^)
$ echo "$old" >.git/refs/heads/master ;# rewind further
$ git checkout -f master
$ git prune ;# try losing a bit more objects.
$ git pull origin master
$ git ls-remote ./. ;# show me my refs
$ git ls-remote origin ;# show me his refs
Unlike my other shell scripts I usually write in my e-mail
buffer, I have actually run the above ;-).
-jc
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html