diff options
author | Ævar Arnfjörð Bjarmason <avarab@gmail.com> | 2019-01-19 21:21:17 +0100 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2019-01-23 13:14:08 -0800 |
commit | d9b1b309cfc0ebbe5ac689e1131f8c85b025c8c7 (patch) | |
tree | a6db2e3e2b9f931c3a7d7179d7c414903963228c /fuzz-pack-headers.c | |
parent | commit-graph write: more descriptive "writing out" output (diff) | |
download | tgif-d9b1b309cfc0ebbe5ac689e1131f8c85b025c8c7.tar.xz |
commit-graph write: show progress for object search
Show the percentage progress for the "Finding commits for commit
graph" phase for the common case where we're operating on all packs in
the repository, as "commit-graph write" or "gc" will do.
Before we'd emit on e.g. linux.git with "commit-graph write":
Finding commits for commit graph: 6529159, done.
[...]
And now:
Finding commits for commit graph: 100% (6529159/6529159), done.
[...]
Since the commit graph only includes those commits that are packed
(via for_each_packed_object(...)) the approximate_object_count()
returns the actual number of objects we're going to process.
Still, it is possible due to a race with "gc" or another process
maintaining packs that the number of objects we're going to process is
lower than what approximate_object_count() reported. In that case we
don't want to stop the progress bar short of 100%. So let's make sure
it snaps to 100% at the end.
The inverse case is also possible and more likely. I.e. that a new
pack has been added between approximate_object_count() and
for_each_packed_object(). In that case the percentage will go beyond
100%, and we'll do nothing to snap it back to 100% at the end.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'fuzz-pack-headers.c')
0 files changed, 0 insertions, 0 deletions