aboutsummaryrefslogtreecommitdiff
path: root/builtin-count-objects.c
Commit message (Collapse)AuthorAge
* count-objects -v: show number of packs as well.Junio C Hamano2006-12-27
| | | | | | | | | Recent "git push" keeps transferred objects packed much more aggressively than before. Monitoring output from git-count-objects -v for number of loose objects is not enough to decide when to repack -- having too many small packs is also a good cue for repacking. Signed-off-by: Junio C Hamano <junkio@cox.net>
* pack-objects --unpacked=<existing pack> option.Junio C Hamano2006-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* builtins: Makefile clean-upJunio C Hamano2006-08-04
This cleans up the build procedure for built-in commands by: - generating mostly redundant definition of BUILT_INS from BUILTIN_OBJS in the Makefile, - renaming a few files to make the above possible, and - sorting the built-in command table in git.c. It might be a good idea to binary search (or perfect hash) the built-in command table, but that can be done later when somebody feels like. Signed-off-by: Junio C Hamano <junkio@cox.net>