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

[Junio C Hamano <gitster@pobox.com>]

Aleksei Sviridkin <f@lex.la> writes:

> 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.

Sorry but I am confused.  Your sample below is with 20000 local
reflog worth of activities, which is hardly a "quiet repository".
Besides, we are talking about "push" so optimizing for a quiet
repository does not sound like a useful mentail exercise to do.

>> 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.

Thanks.

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?