pack-objects --unpacked=<existing pack> option.
commit106d710bc13f34aec1a15c4cff80f062f384edf6
authorJunio C Hamano <junkio@cox.net>
Wed, 6 Sep 2006 09:12:09 +0000 (6 02:12 -0700)
committerJunio C Hamano <junkio@cox.net>
Thu, 7 Sep 2006 09:46:03 +0000 (7 02:46 -0700)
treee6ff5d78fca3d9292cf71e47a97c4671b6b5a0ec
parent8d1d8f83b5d918c6071b606e321de9c31fed9e68
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>
builtin-count-objects.c
builtin-prune-packed.c
cache.h
revision.c
revision.h
sha1_file.c