Re: [PATCH v2] push: fix --force-if-includes when remote-tracking ref has no reflog

From: Aleksei Sviridkin <f@lex.la>
Date: Sep 9, 2026, 06:56 UTC
Message-ID: <20260909065639.47316-1-f@lex.la>
In-Reply-To: <xmqqjyowz9oq.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

> It is only true for those who conciously disable the gc, isn't it?

No. The fallback is not about expiry, it is reached when the remote-tracking ref has no reflog, and a plain clone leaves it that way: after "git clone --no-local" on the files backend, "git reflog exists refs/remotes/origin/main" returns 1, with core.logAllRefUpdates at its default and gc untouched. The same source cloned with --ref-format=reftable gets one entry.

Nothing expires on a calendar either. Entries go when "git reflog expire" runs, and "git gc --auto" decides by loose object count (gc.auto, 6700), so a quiet repository expires nothing.

> Doesn't it force a behaviour that would happen only to those people
> who deliberately choose to ignore cutoff and who are willing to spend
> cycles to go back to the beginning of history, to all users,
> including those who do not make such customization, no?

Measured that. One repository, 20000 entries in the local branch's reflog, remote-tracking ref without a reflog, both values reject the push so only the work differs. Median of 7 runs:

  entries spread over 200 days      zero 0.325s   90 days 0.069s
  after "git reflog expire --all"   zero 0.070s   90 days 0.069s
  20000 entries inside 90 days      zero 0.319s   90 days 0.321s

The expire run left 5 of the 20000, since all but five are 100 to 200 days old here. So the cost lands only on a repository that still holds entries older than 90 days, which is the one where gc has not run.

In that repository, when the matching entry is one of the old ones, the same walk is what decides: zero accepts in 0.322s, 90 days rejects in 0.086s.

With no match it is 0.26s of extra work for the same answer.