Re: [PATCH v2] reflog: fix default expiry periods
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Sep 28, 2026, 06:53 UTC
- Message-ID
- <aroO0x0Ptp09ncx_@pks.im>
- In-Reply-To
- <20260924184331.GB747880@coredump.intra.peff.net>
On Thu, Sep 24, 2026 at 02:43:31PM -0400, Jeff King wrote:
Show 24 quoted lines
> On Thu, Sep 24, 2026 at 10:45:21AM -0700, Junio C Hamano wrote:
> > Jeff King <peff@peff.net> writes:
> > > On Thu, Sep 24, 2026 at 04:12:04PM +0200, Patrick Steinhardt wrote:
> > >
> > >> > > #define REFLOG_EXPIRE_OPTIONS_INIT(now) { \
> > >> > > - .default_expire_total = now - 30 * 24 * 3600, \
> > >> > > - .default_expire_unreachable = now - 90 * 24 * 3600, \
> > >> > > + .default_expire_total = now - 90 * 24 * 3600, \
> > >> > > + .default_expire_unreachable = now - 30 * 24 * 3600, \
> > >> > > }
> > >> >
> > >> > and the fix is very straight-forward.
> > >>
> > >> Is this something that we want to fast-track for Git 2.56?
> > >
> > > The breakage was in v2.50.0, so it is not a new regression. OTOH it
> > > seems quite obvious and low-risk. I'd be OK either way.
> >
> > Yeah, I didn't know the breakage was that old. Perhaps not many
> > people are paying attention to reflog expiration?
>
> Quite probably. The default expiration dates are somewhat arbitrary, and
> the reflogs themselves are somewhat ephemeral. Probably people would
> notice most on stashes, but those are also somewhat ephemeral.Oh, I didn't realize that, either. In that case I agree it's not necessary to fast-track this. Thanks!
Patrick