summaryrefslogtreecommitdiff
path: root/worktree.c
diff options
context:
space:
mode:
authorLibravatar Ævar Arnfjörð Bjarmason <avarab@gmail.com>2019-01-19 21:21:17 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-01-23 13:14:08 -0800
commitd9b1b309cfc0ebbe5ac689e1131f8c85b025c8c7 (patch)
treea6db2e3e2b9f931c3a7d7179d7c414903963228c /worktree.c
parentcommit-graph write: more descriptive "writing out" output (diff)
downloadtgif-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 'worktree.c')
0 files changed, 0 insertions, 0 deletions