mbox series

[00/12] reflog + gc: refactor, progress output, reftable-readyness

Message ID cover-00.12-00000000000-20211130T213319Z-avarab@gmail.com (mailing list archive)
Headers show
Series reflog + gc: refactor, progress output, reftable-readyness | expand

Message

Ævar Arnfjörð Bjarmason Nov. 30, 2021, 9:38 p.m. UTC
This is a follow-up topic I had for my "errno" refs API changes that
just landed[1]. I initially thought I'd split this into multiple
submissions, but I think it's probably better to consider it in
unison.

Comments on individual patches below:

1. https://lore.kernel.org/git/cover-v2-00.21-00000000000-20211016T093845Z-avarab@gmail.com/

Ævar Arnfjörð Bjarmason (12):
  reflog delete: narrow scope of "cmd" passed to count_reflog_ent()
  reflog expire: narrow scope of "cb" in cmd_reflog_expire()
  reflog: change one->many worktree->refnames to use a string_list
  reflog expire: don't do negative comparison on enum values
  reflog expire: refactor & use "tip_commit" only for UE_NORMAL
  reflog expire: don't use lookup_commit_reference_gently()
  reflog: reduce scope of "struct rev_info"
  refs files-backend: assume cb->newlog if !EXPIRE_REFLOGS_DRY_RUN

This is all refactorings to make the reflog-related code smaller,
easier to read, using string-list instead of a custom home-grown flex
array API etc, and to make it clear what variables and data is used
where. This really helps for subsequent steps.

  reflog + refs-backend: move "verbose" out of the backend

As noted in
https://lore.kernel.org/git/211123.864k83w3y4.gmgdl@evledraar.gmail.com/
this makes the "verbose" API independent, so the reftable backend
we'll have soon won't need to do anything special to support it.

It used to conflict with Han-Wen's topic, but in his v2 he picked
another approach.

  reflog expire: add progress output on --stale-fix
  gc + reflog: emit progress output from "reflog expire --all"
  gc + reflog: don't stall before initial "git gc" progress output

These are all progress additions to "reflog expire" including fixing
the long-standing oddity that on large repos "git gc"'s progress seems
to simply hang before reaching "Enumerating objects".

As noted in 12/12 this is partly a bit of a hack, but I've got other
in-flight progress.c API changes that'll eventually lead to supporting
"nested" progress bars, which this code will be one of the first
consumers of.

 Documentation/git-reflog.txt |   8 ++
 builtin/gc.c                 |   4 +-
 builtin/reflog.c             | 260 ++++++++++++++++++++++-------------
 refs.h                       |   3 +-
 refs/files-backend.c         |  44 +++---
 5 files changed, 194 insertions(+), 125 deletions(-)