From: Aleksei Sviridkin Date: Thu, 10 Sep 2026 08:31:06 GMT Subject: Re: [PATCH v2] push: fix --force-if-includes when remote-tracking ref has no reflog Message-ID: <20260910083106.88960-1-f@lex.la> In-Reply-To: Junio C Hamano writes: > Sorry but I am confused. Your sample below is with 20000 local > reflog worth of activities, which is hardly a "quiet repository". Two things got joined there. The 20000 entries are the worst case for measuring the walk's cost. The repositories that keep entries older than 90 days are ordinary ones where "git gc --auto" never crossed 6700 loose objects, and that needs no configuration. > Doesn't that mean it is more logical to use the default gc > expiration timeout than year 1970 and in any cases using the usual > gc expiration would not waste more time than using 1970, right? On time, yes. The cutoff never takes longer than zero. But it saves time only by ending the search early, and ending the search early is what rejects a valid push. Same repository, matching entry 200 days old: the cutoff rejects in 0.086s, zero accepts in 0.322s. Where the cutoff cannot change the verdict, both take the same time: 0.070s vs 0.069s after expiry, 0.319s vs 0.321s with everything inside 90 days. The cutoff is faster than zero only where it gives the wrong answer. If that trade is acceptable, gc.reflogExpire is a one-line change, and the commit message should then say the fallback can still reject a correct push when the matching entry is older than the cutoff. Your call.