1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 22:07:53 +01:00
git/builtin/prune-packed.c

68 lines
1.5 KiB
C
Raw Normal View History

#include "builtin.h"
#include "cache.h"
#include "progress.h"
#include "parse-options.h"
#include "packfile.h"
static const char * const prune_packed_usage[] = {
N_("git prune-packed [-n | --dry-run] [-q | --quiet]"),
NULL
};
static struct progress *progress;
static int prune_subdir(unsigned int nr, const char *path, void *data)
{
int *opts = data;
display_progress(progress, nr + 1);
if (!(*opts & PRUNE_PACKED_DRY_RUN))
rmdir(path);
return 0;
}
static int prune_object(const struct object_id *oid, const char *path,
void *data)
{
int *opts = data;
if (!has_sha1_pack(oid->hash))
return 0;
if (*opts & PRUNE_PACKED_DRY_RUN)
printf("rm -f %s\n", path);
else
unlink_or_warn(path);
return 0;
}
void prune_packed_objects(int opts)
{
if (opts & PRUNE_PACKED_VERBOSE)
progress: simplify "delayed" progress API We used to expose the full power of the delayed progress API to the callers, so that they can specify, not just the message to show and expected total amount of work that is used to compute the percentage of work performed so far, the percent-threshold parameter P and the delay-seconds parameter N. The progress meter starts to show at N seconds into the operation only if we have not yet completed P per-cent of the total work. Most callers used either (0%, 2s) or (50%, 1s) as (P, N), but there are oddballs that chose more random-looking values like 95%. For a smoother workload, (50%, 1s) would allow us to start showing the progress meter earlier than (0%, 2s), while keeping the chance of not showing progress meter for long running operation the same as the latter. For a task that would take 2s or more to complete, it is likely that less than half of it would complete within the first second, if the workload is smooth. But for a spiky workload whose earlier part is easier, such a setting is likely to fail to show the progress meter entirely and (0%, 2s) is more appropriate. But that is merely a theory. Realistically, it is of dubious value to ask each codepath to carefully consider smoothness of their workload and specify their own setting by passing two extra parameters. Let's simplify the API by dropping both parameters and have everybody use (0%, 2s). Oh, by the way, the percent-threshold parameter and the structure member were consistently misspelled, which also is now fixed ;-) Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19 19:39:41 +02:00
progress = start_delayed_progress(_("Removing duplicate objects"), 256);
for_each_loose_file_in_objdir(get_object_directory(),
prune_object, NULL, prune_subdir, &opts);
/* Ensure we show 100% before finishing progress */
display_progress(progress, 256);
stop_progress(&progress);
}
int cmd_prune_packed(int argc, const char **argv, const char *prefix)
{
int opts = isatty(2) ? PRUNE_PACKED_VERBOSE : 0;
const struct option prune_packed_options[] = {
OPT_BIT('n', "dry-run", &opts, N_("dry run"),
PRUNE_PACKED_DRY_RUN),
OPT_NEGBIT('q', "quiet", &opts, N_("be quiet"),
PRUNE_PACKED_VERBOSE),
OPT_END()
};
argc = parse_options(argc, argv, prefix, prune_packed_options,
prune_packed_usage, 0);
prune_packed_objects(opts);
return 0;
}