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>

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.