From: Taylor Blau <me@ttaylorr.com>
To: git@vger.kernel.org
Cc: Jeff King <peff@peff.net>, Chris Torek <chris.torek@gmail.com>,
Derrick Stolee <derrickstolee@github.com>,
Junio C Hamano <gitster@pobox.com>,
Glen Choo <chooglen@google.com>
Subject: [PATCH v5 0/2] gc: introduce `gc.recentObjectsHook`
Date: Wed, 7 Jun 2023 18:58:07 -0400 [thread overview]
Message-ID: <cover.1686178684.git.me@ttaylorr.com> (raw)
In-Reply-To: <cover.1683847221.git.me@ttaylorr.com>
Here is a version of my series to implement the mutli-valued
"gc.recentObjectHook" configuration, which allows users to define custom
programs whose output determines an additional set of objects to retain
(along with their descendants) when GCing, regardless of their true age.
It is largely the same as the previous round, with the following
changes:
- a small handful of wordsmithing changes in the second patch's
message thanks to a very helpful review from the Google team's
"Review Club" meeting.
- removed a pair of stray references to "cruft tips" in favor of
"recent objects".
- rebased onto v2.41.0
Based on previous rounds of review, I think that this version should be
pretty much ready to go. But I'd appreciate some extra eyes on it just
to make sure.
Thanks in advance for your (hopefully final!) review.
Taylor Blau (2):
reachable.c: extract `obj_is_recent()`
gc: introduce `gc.recentObjectsHook`
Documentation/config/gc.txt | 15 +++
reachable.c | 85 ++++++++++++-
t/t5304-prune.sh | 14 +++
t/t5329-pack-objects-cruft.sh | 171 +++++++++++++++++++++++++++
t/t7701-repack-unpack-unreachable.sh | 31 +++++
5 files changed, 313 insertions(+), 3 deletions(-)
Range-diff against v4:
1: 9c1b59c8cf = 1: 38c4c4a17f reachable.c: extract `obj_is_recent()`
2: 18e50d2517 ! 2: f661b54941 gc: introduce `gc.recentObjectsHook`
@@ Commit message
be pruned. Our options today consist of:
- Point references at the reachability tips of any objects you
- consider precious, which may be undesirable or infeasible.
+ consider precious, which may be undesirable or infeasible if there
+ are many such objects.
- Track them via the reflog, which may be undesirable since the
reflog's lifetime is limited to that of the reference it's tracking
@@ Documentation/config/gc.txt: or rebase occurring. Since these changes are not p
default is more aggressive than `gc.reflogExpire`.
+gc.recentObjectsHook::
-+ When considering the recency of an object (e.g., when generating
-+ a cruft pack or storing unreachable objects as loose), use the
-+ shell to execute the specified command(s). Interpret their
-+ output as object IDs which Git will consider as "recent",
-+ regardless of their age.
++ When considering whether or not to remove an object (either when
++ generating a cruft pack or storing unreachable objects as
++ loose), use the shell to execute the specified command(s).
++ Interpret their output as object IDs which Git will consider as
++ "recent", regardless of their age. By treating their mtimes as
++ "now", any objects (and their descendants) mentioned in the
++ output will be kept regardless of their true age.
++
+Output must contain exactly one hex object ID per line, and nothing
+else. Objects which cannot be found in the repository are ignored.
@@ reachable.c: struct recent_data {
+ ret = run_one_gc_recent_objects_hook(&data->extra_recent_oids,
+ programs->items[i].string);
+ if (ret)
-+ die(_("unable to enumerate additional cruft tips"));
++ die(_("unable to enumerate additional recent objects"));
+ }
+}
+
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend v
+ # ensure that a dirty exit halts cruft pack generation
+ git config --add gc.recentObjectsHook ./extra-tips.c &&
+ test_must_fail git repack --cruft --cruft-expiration=now -d 2>err &&
-+ grep "unable to enumerate additional cruft tips" err &&
++ grep "unable to enumerate additional recent objects" err &&
+
+ # and that the existing cruft pack is left alone
+ test_path_is_file "$mtimes"
--
2.41.0.2.gaaae24b3a6.dirty
next prev parent reply other threads:[~2023-06-07 22:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 23:20 [PATCH v3 0/2] pack-objects: introduce `pack.extraRecentObjectsHook` Taylor Blau
2023-05-11 23:20 ` [PATCH v3 1/2] reachable.c: extract `obj_is_recent()` Taylor Blau
2023-05-11 23:20 ` [PATCH v3 2/2] builtin/pack-objects.c: introduce `pack.recentObjectsHook` Taylor Blau
2023-05-12 4:58 ` Jeff King
2023-05-15 20:15 ` Taylor Blau
2023-05-12 21:24 ` Jeff King
2023-05-12 21:36 ` Taylor Blau
2023-05-12 21:46 ` Jeff King
2023-05-12 21:45 ` Jeff King
2023-05-12 22:01 ` Jeff King
2023-05-12 23:21 ` Junio C Hamano
2023-05-13 0:11 ` Jeff King
2023-05-13 0:11 ` Jeff King
2023-05-15 20:49 ` Taylor Blau
2023-05-15 20:38 ` Taylor Blau
2023-05-11 23:23 ` [PATCH v3 0/2] pack-objects: introduce `pack.extraRecentObjectsHook` Taylor Blau
2023-05-11 23:39 ` Junio C Hamano
2023-05-11 23:48 ` Taylor Blau
2023-05-16 0:23 ` [PATCH v4 0/2] gc: introduce `gc.recentObjectsHook` Taylor Blau
2023-05-16 0:24 ` [PATCH v4 1/2] reachable.c: extract `obj_is_recent()` Taylor Blau
2023-05-16 0:24 ` [PATCH v4 2/2] gc: introduce `gc.recentObjectsHook` Taylor Blau
2023-05-24 23:21 ` Glen Choo
2023-06-07 22:56 ` Taylor Blau
2023-06-07 22:58 ` Taylor Blau [this message]
2023-06-07 22:58 ` [PATCH v5 1/2] reachable.c: extract `obj_is_recent()` Taylor Blau
2023-06-07 22:58 ` [PATCH v5 2/2] gc: introduce `gc.recentObjectsHook` Taylor Blau
2023-06-09 23:33 ` Glen Choo
2023-06-12 21:14 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1686178684.git.me@ttaylorr.com \
--to=me@ttaylorr.com \
--cc=chooglen@google.com \
--cc=chris.torek@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).