Re: [PATCH 3/8] t34xx: don't expire reflogs where it matters
- From
Justin Tobler <jltobler@gmail.com>
- Date
- Feb 23, 2026, 16:15 UTC
- Message-ID
- <aZx72rF8OOXryMc5@denethor>
- In-Reply-To
- <20260220-b4-pks-maintenance-default-geometric-strategy-v1-3-faeb321ad13b@pks.im>
On 26/02/20 11:15AM, Patrick Steinhardt wrote:
Show 25 quoted lines
> We have a couple of tests in the t34xx range that rely on reflogs. This > never really used to be a problem, but in a subsequent commit we will > change the default maintenance strategy from "gc" to "geometric", and > this will cause us to drop all reflogs in these tests. > > This may seem surprising and like a bug at first, but it's actually not. > The main difference between these two strategies is that the "gc" > strategy will skip all maintenance in case the object database is in a > well-optimized state. The "geometric" strategy has separate subtasks > though, and the conditions for each of these tasks is evaluated on a > case by case basis. This means that even if the object database is in > good shape, we may still decide to expire reflogs. > > So why is that a problem? The issue is that Git's test suite hardcodes > the committer and author dates to a date in 2005. Interestingly though, > these hardcoded dates not only impact the commits, but also the reflog > entries. The consequence is that all newly written reflog entries are > immediately considered stale as our reflog expiration threshold is in > the range of weeks, only. It follows that executing `git reflog expire` > will thus immediately purge all reflog entries. > > This hasn't been a problem in our test suite by pure chance, as the > repository shapes simply didn't cause us to perform actual garbage > collection. But with the upcoming "geometric" strategy we _will_ start > to execute `git reflog expire`, thus surfacing this issue.
Interesting find.
> Prepare for this by explicitly disabling reflog expiration in tests > impacted by this upcoming change.
Makes sense.
Show 18 quoted lines
> Signed-off-by: Patrick Steinhardt <ps@pks.im> > --- > t/t3404-rebase-interactive.sh | 2 ++ > t/t3406-rebase-message.sh | 3 +++ > t/t3431-rebase-fork-point.sh | 2 ++ > t/t3432-rebase-fast-forward.sh | 2 ++ > 4 files changed, 9 insertions(+) > > diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh > index e778dd8ae4..5e4623f7f1 100755 > --- a/t/t3404-rebase-interactive.sh > +++ b/t/t3404-rebase-interactive.sh > @@ -31,6 +31,8 @@ Initial setup: > . "$TEST_DIRECTORY"/lib-rebase.sh > > test_expect_success 'setup' ' > + git config set gc.reflogExpire never && > + git config set gc.reflogExpireUnreachable never &&
As it may not be immediately obvious, it could be helpful for future readers to explain in a comment that reflog dates are hardcoded to a date that would be immediately expired and thus the need for this configuration.
This patch looks good to me.
-Justin