summaryrefslogtreecommitdiff
path: root/http-fetch.c
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2006-09-06 09:12:09 (GMT)
committerJunio C Hamano <junkio@cox.net>2006-09-07 09:46:03 (GMT)
commit106d710bc13f34aec1a15c4cff80f062f384edf6 (patch)
treee6ff5d78fca3d9292cf71e47a97c4671b6b5a0ec /http-fetch.c
parent8d1d8f83b5d918c6071b606e321de9c31fed9e68 (diff)
downloadgit-106d710bc13f34aec1a15c4cff80f062f384edf6.zip
git-106d710bc13f34aec1a15c4cff80f062f384edf6.tar.gz
git-106d710bc13f34aec1a15c4cff80f062f384edf6.tar.bz2
pack-objects --unpacked=<existing pack> option.
Incremental repack without -a essentially boils down to: rev-list --objects --unpacked --all | pack-objects $new_pack which picks up all loose objects that are still live and creates a new pack. This implements --unpacked=<existing pack> option to tell the revision walking machinery to pretend as if objects in such a pack are unpacked for the purpose of object listing. With this, we could say: rev-list --objects --unpacked=$active_pack --all | pack-objects $new_pack instead, to mean "all live loose objects but pretend as if objects that are in this pack are also unpacked". The newly created pack would be perfect for updating $active_pack by replacing it. Since pack-objects now knows how to do the rev-list's work itself internally, you can also write the above example by: pack-objects --unpacked=$active_pack --all $new_pack </dev/null Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'http-fetch.c')
0 files changed, 0 insertions, 0 deletions