path: root/builtin-prune-packed.c
AgeCommit message (Collapse)Author
2007-11-01return the prune-packed progress display to the inner loopNicolas Pitre
This reverts commit 0e549137966feb016927a827fb6e359aec8264a3 so to return to the same state as commit b5d72f0a4cd3cce945ca0d37e4fa0ebbfcdcdb52. On Wed, 31 Oct 2007, Shawn O. Pearce wrote: > During my testing with a 40,000 loose object case (yea, I fully > unpacked a git.git clone I had laying around) my system stalled > hard in the first object directory. A *lot* longer than 1 second. > So I got no progress meter for a long time, and then a progress > meter appeared on the second directory. Signed-off-by: Nicolas Pitre <> Signed-off-by: Junio C Hamano <>
2007-10-30relax usage of the progress APINicolas Pitre
Since it is now OK to pass a null pointer to display_progress() and stop_progress() resulting in a no-op, then we can simplify the code and remove a bunch of lines by not making those calls conditional all the time. Signed-off-by: Nicolas Pitre <> Signed-off-by: Junio C Hamano <>
2007-10-30make struct progress an opaque typeNicolas Pitre
This allows for better management of progress "object" existence, as well as making the progress display implementation more independent from its callers. Signed-off-by: Nicolas Pitre <> Signed-off-by: Junio C Hamano <>
2007-10-30prune-packed: don't call display_progress() for every fileNicolas Pitre
The progress count is per fanout directory, so it is useless to call it for every file as the count doesn't change that often. Signed-off-by: Nicolas Pitre <> Signed-off-by: Junio C Hamano <>
2007-10-19Teach prune-packed to use the standard progress meterShawn O. Pearce
Rather than reimplementing the progress meter logic and always showing 100 lines of output while pruning already packed objects we now use a delayed progress meter and only show it if there are enough objects to make us take a little while. Most users won't see the message anymore as it usually doesn't take very long to delete the already packed loose objects. This neatens the output of a git-gc or git-repack execution, which is especially important for a `git gc --auto` triggered from within another command. We perform the display_progress() call from within the very innermost loop in case we spend more than 1 second within any single object directory. This ensures that a progress_update event from the timer will still trigger in a timely fashion and allow the user to see the progress meter. While I'm in here I changed the message to be more descriptive of its actual task. "Removing unused objects" is a little scary for new users as they wonder where these unused objects came from and how they should avoid them. Truth is these objects aren't unused in the sense of what git-prune would call a dangling object, these are used but are just duplicates of things we have already stored in a packfile. Signed-off-by: Shawn O. Pearce <>
2007-01-18prune-packed: add -q to usageMatthias Lederhofer
Signed-off-by: Junio C Hamano <>
2007-01-12Make git-prune-packed a bit more chatty.Junio C Hamano
Steven Grimm noticed that git-repack's verbosity is inconsistent because pack-objects is chatty and prune-packed is not. This makes the latter a bit more chatty and gives -q option to squelch it. Signed-off-by: Junio C Hamano <>
2006-10-23prune-packed: Fix uninitialized variable.Alexandre Julliard
The dryrun variable was made local instead of static by the previous commit, and local variables aren't initialized to zero. Signed-off-by: Alexandre Julliard <> Signed-off-by: Junio C Hamano <>
2006-10-22Make prune also run prune-packedJ. Bruce Fields
Both the git-prune manpage and everday.txt say that git-prune should also prune unpacked objects that are also found in packs, by running git prune-packed. Junio thought this was "a regression when prune was rewritten as a built-in." So modify prune to call prune-packed again. Signed-off-by: J. Bruce Fields <>
2006-09-07pack-objects --unpacked=<existing pack> option.Junio C Hamano
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 <>
2006-08-03use declarations from builtin.h for builtin commandsMatthias Kestenholz
Signed-off-by: Matthias Kestenholz <> Signed-off-by: Junio C Hamano <>
2006-08-02Make git-prune-packed a builtinMatthias Kestenholz
Signed-off-by: Matthias Kestenholz <> Signed-off-by: Junio C Hamano <>