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

Since 99a1f9ae10 (push: add reflog check for "--force-if-includes", 2020-10-03), is_reachable_in_reflog() looks for the remote tip in the local branch's reflog and stops at entries older than the newest entry of the remote-tracking ref's reflog. That timestamp comes from a callback of refs_for_each_reflog_ent_reverse(), which never runs when the remote-tracking ref has no reflog, so the variable stays uninitialized.

With the files backend a remote-tracking ref that "git clone" created has no reflog until it moves. On my machine the leftover value exceeded any real timestamp, so the walk stopped at the first entry and the push was rejected with "remote ref updated since checkout" though nothing on the remote had changed.

That stopping point assumes an entry older than the last recorded move of the remote-tracking ref cannot be the one we want. The record itself can be missing: never written, deleted, or expired by gc. Initialize the timestamp to zero for a missing record. timestamp_t is unsigned, so nothing compares older and the walk stops only at the remote tip or at the end of the local reflog. "Now" brings the bug straight back. A fixed age narrows it: the push is rejected when the remote tip is recorded only past the first entry older than that age and nothing collected reaches it.

When the remote tip is not in the local reflog at all, a stopped walk and a full one fall back to the same merge-base check, and the full one hands it more entries.

Signed-off-by: Aleksei Sviridkin <f@lex.la>
---
Changes since v3:

- log message rewritten. Two things in it were wrong, not just
  unclear: it read as if a walk that stops at the cut-off skips the
  merge-base check, and it said there is "no such moment" when what is
  missing is the record of it.
- test uses setup_src_dup_dst and expires only the remote-tracking
  reflog.

t5533 passes 24/24 with the fix on files and on reftable, and the new test fails on both without it. That failure is only reliable when built with

	make CFLAGS_APPEND=-ftrivial-auto-var-init=pattern

otherwise the stack may hold a small number, as on your machine. So CI would not catch this going uninitialized again.

One detail the expire hides: on files it leaves no reflog at all, on reftable an empty one. The callback does not run either way.

The batch size growth looks worth its own patch. Not touched here.

 remote.c            |  2 +-
 t/t5533-push-cas.sh | 16 ++++++++++++++++
 2 files changed, 17 insertions(+), 1 deletion(-)