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

On 26-09-09 17:57:01, Junio C Hamano wrote:

<snip>

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?

I like date=0 (i.e., 1970).

Tested locally, in _most_ cases both give the right answer. But
date=<cutoff> can give the wrong answer in a subset of cases, and date=0
can give a slower answer in a subset of cases.

I think the wrong answer is worse, and I think the case where
date=<cutoff> provides a wrong answer is common for me (with default gc
settings and lots of old git clones).

The important bits of is_reachable_in_reflog:

- date: initial: either gc.reflogExpire (default: 90 days) or 0. Later:
  maybe set by a walk of remote reflog.
- remote: e.g., remotes/origin/<x>
- local: e.g., refs/heads/<x>
- remote->old_oid: advertised oid for remote ref

We need to find remote->old_oid in the local reflog. We can't build on a
commit we've never fetched, so we set date to the last time remote's
reflog moved to bound our walk of local.

But remote's reflog can expire or be empty, so it needs an initial
value.

With date=0 (and remote gone: older than 90 days + gc, removed, or fresh
clone), we walk local until we find the remote->old_oid or we run out of
reflog to walk. But local is also subject to gc, so by default that's 90
days without having to bound anything. Since both reflogs are gc'd, the
time difference should be minimal.

With date=<cutoff> is only faster where we have no remote reflog, we
don't have remote->old_oid in our local, and our local reflog has
entries older than the typical gc cutoff; viz. I'm rebuilding history
without the remote tip and: (a) expired my remote reflog manually (b)
have my remote reflog gc configured differently than my local or (c) I
have gc turned off.

But in one case, date=0 gives the right answer and the cutoff date gives
the wrong answer:

    git clone ...            # 1. files backend, no remote reflog
    git reset --hard HEAD^   # 2. start a rewrite
    ...                      # 3. do nothing for gc.reflogExpire amount
    ...                      #    of time.
    ...                      #    Remote never moves/we never fetch.
    git commit ...           # 4. Finish rewrite and push
    git push --force-if-includes --force-with-lease origin main

Push fails with date=gc.reflogExpire (wrong). Push succeeds with date=0
(right).

And nothing about gc config need be tweaked from the defaults for this
to happen---git gc can even happen (provided it runs between the initial
clone and the reset, since the reflogUnreachable prune is 30 days by
default). But in small repos, gc may not have been triggered at all.

So date=0 is always correct and should have equivalent in runtime in
most cases. And it neatly side-steps what cut off should we use?
gc.reflogExpire vs.  gc.<remote>.reflogExpire vs.
gc.<local>.reflogExpire vs. flat 90 days vs. do we respect
gc.reflogExpire=never.

Thanks.