Since 99a1f9ae10 (push: add reflog check for "--force-if-includes", 2020-10-03), is_reachable_in_reflog() stops walking the reflog of the local branch at entries older than the newest reflog entry of the remote-tracking ref. That timestamp is read by a callback of refs_for_each_reflog_ent_reverse() into a variable that is never initialized, so when the remote-tracking ref has no reflog the walk is cut off at whatever happens to be on the stack.

With the files backend a remote-tracking ref created by "git clone" has no reflog and does not get one until it moves. On my machine the leftover value exceeds any real timestamp: the walk stops at the very first entry, never reaches the "Created from" entry that "checkout --track" wrote, and the push is rejected with "remote ref updated since checkout" although nothing on the remote has changed.

Initialize the timestamp to zero, so that a remote-tracking ref without reflog makes the walk cover the whole reflog of the local branch, as documented.

Signed-off-by: Aleksei Sviridkin <f@lex.la>
Assisted-by: LLM
---
The new test fails without the fix on my machine (macOS, arm64). As
the value read is uninitialized, other platforms may pass it by luck.

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

Aleksei Sviridkin <f@lex.la> writes:

The last line adds no useful information, though. Besides, you are fully responsible for whatever LLM emitted and contributed into this patch, so your sign-off must be the last line in the trailers.

The code change looks good.

It is a bit surprising to see the fallout from a change 6 years ago to be addressed now, and makes me wonder what else changed recently. Certainly year 2026 is not the first year in which macOS on arm64 started becoming widely used, or you are not the only user of Git on that platform.

You'd want to move "test_when_finished" immediately before "git init --bare dst", no? That way, you can clean things up after any or the "init", "push", "clone" fails (as well as the main part of the test that is done in the subdirectory).

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

I took Assisted-by from the kernel, which asks for it. I could not find anything either way in git's guidelines, so I followed the kernel. I will put the sign-off last in v2, and drop Assisted-by if you would rather not have it.

The date is read from uninitialized stack, so it only bites when the leftover happens to be larger than a real timestamp. That is build- and layout-dependent, not really macOS/arm64 specific. I hit a layout where it triggers every time, so the test is reliable here, but on another build it can pass by luck, as you saw.

Aleksei Sviridkin <f@lex.la> writes:

I didn't mean to say that Assisted-by was useless. What I meant was that "LLM" on that trailer has no information contennts. Which LLM?

We have the following in Documentation/SubmittingPatches by the way.

[[ai]] === Use of Artificial Intelligence (AI)

The Developer's Certificate of Origin requires contributors to certify that they know the origin of their contributions to the project and that they have the right to submit it under the project's license. It's not yet clear that this can be legally satisfied when submitting significant amount of content that has been generated by AI tools.

Another issue with AI generated content is that AIs still often hallucinate or just produce bad code, commit messages, documentation or output, even when you point out their mistakes.

To avoid these issues, we will reject anything that looks AI generated, that sounds overly formal or bloated, that looks like AI slop, that looks good on the surface but makes no sense, or that senders don’t understand or cannot explain.

We strongly recommend using AI tools carefully and responsibly.

Contributors would often benefit more from AI by using it to guide and help them step by step towards producing a solution by themselves rather than by asking for a full solution that they would then mostly copy-paste. They can also use AI to help with debugging, or with checking for obvious mistakes, things that can be improved, things that don’t match our style, guidelines or our feedback, before sending it to us.

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

On "which LLM": I took the trailer from the kernel, and they dropped the
model name on purpose. Christian Brauner's 816d9992d9ed
(coding-assistants: simplify attribution) turned
Assisted-by: AGENT_NAME:MODEL_VERSION into a bare Assisted-by: LLM,
because naming the model "provides free advertising to proprietary
software companies while adding little or no useful information". It
fits my case anyway: this went through a router mixing models from three
vendors, so there is no single model to name, and git's guidelines don't
ask for one either. In case you are curious: k3, sol-5.6, fable 5.1,
opus 5 and sonnet 5. If you would still rather I drop the trailer, I
will.

I read the AI section. These are small fixes, I went through the whole change myself and can explain any part of it. I'll keep what I send lean.

v2 with the sign-off last and the test_when_finished fix goes out once 24 hours have passed since v1.

On Thu, Sep 3, 2026, at 22:00, Aleksei Sviridkin wrote:

If there is no mention of it in the guidelines the fallback guideline becomes the one for an operating system kernel? ’,:|

Maybe you saw the few ones that have landed in the last months in this project. But those don't follow the recent Linux workflow change to just “LLM”.

Since 99a1f9ae10 (push: add reflog check for "--force-if-includes", 2020-10-03), is_reachable_in_reflog() stops walking the reflog of the local branch at entries older than the newest reflog entry of the remote-tracking ref. That timestamp is read by a callback of refs_for_each_reflog_ent_reverse() into a variable that is never initialized, so when the remote-tracking ref has no reflog the walk is cut off at whatever happens to be on the stack.

With the files backend a remote-tracking ref created by "git clone" has no reflog and does not get one until it moves. On my machine the leftover value exceeds any real timestamp: the walk stops at the very first entry, never reaches the "Created from" entry that "checkout --track" wrote, and the push is rejected with "remote ref updated since checkout" although nothing on the remote has changed.

Initialize the timestamp to zero, so that a remote-tracking ref without reflog makes the walk cover the whole reflog of the local branch, as documented.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
---
Changes since v1:
  - sign-off is now the last trailer
  - test_when_finished moved ahead of the setup so a failed init, push
    or clone still cleans up

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

Aleksei Sviridkin <f@lex.la> writes:

This gives a known value to the "date" variable, solving the issue of using an uninitialized variable. But how do we know if "0" a reasonable fall-back value? Why is it better than "now" or perhaps "2 weeks ago"?

We pretend that the latest entry of the remote-tracking ref was from year 1970. And then that timestamp is used as a cut-off time for check_and_collect_until(). What's the ramification of that?

This is almost good as-is. I'd end the above with "... has no reflog, the variable that holds the timestamp stays uninitialized".

That describes what happens (eh, rather, what does not happen) when that uninitialized timestamp is more recent than the current time.

It does not explain why it is sensible to set it to year 1970, which would force everything to be inspected.

Aleksei Sviridkin <f@lex.la> writes:

We are not the kernel ;-)

Quite honestly, I would rather not have patches filled with AI slop that is often walls of text filled with "eh, that may not be wrong per-se, but is it relevant?" descriptions and we can never tell what was used as the original material to copy from. I prefer patches with human-readable explanations and known origin.

Thanks.

Since 99a1f9ae10 (push: add reflog check for "--force-if-includes", 2020-10-03), is_reachable_in_reflog() stops walking the reflog of the local branch at entries older than the newest reflog entry of the remote-tracking ref. That timestamp is read by a callback of refs_for_each_reflog_ent_reverse(), so when the remote-tracking ref has no reflog, the variable that holds the timestamp stays uninitialized.

With the files backend a remote-tracking ref created by "git clone" has no reflog and does not get one until it moves. On my machine the leftover value exceeds any real timestamp: the walk stops at the very first entry, never reaches the "Created from" entry that "checkout --track" wrote, and the push is rejected with "remote ref updated since checkout" although nothing on the remote has changed.

The cut-off is an optimization that rests on an assumption: an entry older than the moment the remote-tracking ref last moved is not expected to be the one being looked for. Without a reflog there is no such moment, hence no cut-off to apply. Initialize the timestamp to zero to say exactly that: timestamp_t is unsigned, so no entry compares older than zero and the comparison never fires. Using "now", or any fixed age, would instead cut the walk off at the first entry older than that bound, which is how the failure happens in the first place. The price is paid only when no matching entry is found: the walk then reaches the oldest entry and falls back to the merge-base check over what it collected, where the cut-off would have stopped it earlier.

Signed-off-by: Aleksei Sviridkin <f@lex.la>
---
Changes since v2:
  - reworded the first paragraph as you suggested
  - explain why zero is the fallback rather than "now" or a fixed age
  - dropped the Assisted-by trailer

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

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

Dropped the trailer. You will not see it again.

On origin: this comes out of git's own tree, not an outside corpus, and that is why every claim in the message names a file or a commit you can check. The change here is one line, timestamp_t date; becoming timestamp_t date = 0;. I read the whole thing and can explain any line of it, and the sign-off is what carries that.

v3 uses your wording for the first paragraph and explains why zero is the right fallback rather than "now" or a fixed age.

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

Thinking about it a bit more, let's imagine that we had reflog enabled and did not have to suffer from this "uninitialized variable" problem. Even if the reflog for the remote-tracking branch were enabled long ago and had plenty of entries, it wouldn't have any entry older than 90 days, or the value gc.reflogExpire is set. Which suggests to me that gc.reflogExpire or 90 days ago would be a lot more reasonable than year 1970 to use as a fallback cutoff date.

Thanks.

On Sat, Sep 5, 2026, at 19:13, Aleksei Sviridkin wrote:

The following are just drive by comments on this point.

On Sat, Sep 5, 2026, at 19:13, Aleksei Sviridkin wrote:

Cool that it is only trained on Git’s corpus.

If one can explain any and all of it, then having an AI write it is not necessary. Referring to the “human-readable explanation” point.

Weird LLM-like phrases like this one seems to be used a lot on these `Assisted-by` submissions (by you and Thomas Bachem recently). Inanimate nouns gain subject-agency in sentences instead of saying something plainly like, I have signed off on this and I mean it. And this is on patch discussions, not in the commit messages (which are already marked as being potentially AI written).

I feel like I should take two courses in linguistics in order to articulate this uncanny valley feeling.

By commit message volume, I would have expected the commit messages (if they are LLM-assisted) to read more like Jeff King log messages given the corpus training.

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

Entries older than 90 days do survive. The reflog expires when gc or "git reflog expire" runs, not on its own, so I could build a branch whose matching reflog entry is 200 days old and still sitting there.

A/B on one scenario with only the fallback differing: with now minus 90 days the push is rejected, with zero it goes through as a forced update. The branch was created at the remote tip 200 days ago, that entry being the matching one, rewound below the tip 150 days ago, one recent commit on top, so the tip is not an ancestor of anything newer.

It takes two crossings of the bound to bite, which is why my first two attempts to reproduce it failed. The match is tested before the cut-off, so the entry sitting at the bound is still inspected, and the merge-base fallback still covers the case where the tip is reachable from something collected. You need a non-matching entry past the bound and the tip unreachable from what was collected.

v3 went out a few hours before your mail; its third paragraph argues zero over "now" or a fixed age. Your call.

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

;-)

On 06/09/2026 19:14, Junio C Hamano wrote:

I can ask for that from the next reroll on, if it helps ;-)

On Mon, Sep 07, 2026 at 06:54:28AM +0200, Thomas Bachem wrote:

I've already had an LLM do this for a while in my toy projects, feeding it a few representative patch series from Peff.

Thanks, Peff! ;-)

Aleksei Sviridkin <f@lex.la> writes:

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

It all depends on how hard it is to recover from such a failure, and it may not even matter in practice what value we set, as it will become a non-issue once they pull from there or push into there even once.

But in the context of discussing what the fallback default ought to be, I somehow sounds more like a poor excuse rather than a sensible argument. 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?

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

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.

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.

Aleksei Sviridkin <f@lex.la> writes:

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.

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?

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

Two things got joined there. The 20000 entries are the worst case for measuring the walk's cost. The repositories that keep entries older than 90 days are ordinary ones where "git gc --auto" never crossed 6700 loose objects, and that needs no configuration.

On time, yes. The cutoff never takes longer than zero. But it saves time only by ending the search early, and ending the search early is what rejects a valid push. Same repository, matching entry 200 days old: the cutoff rejects in 0.086s, zero accepts in 0.322s. Where the cutoff cannot change the verdict, both take the same time: 0.070s vs 0.069s after expiry, 0.319s vs 0.321s with everything inside 90 days.

The cutoff is faster than zero only where it gives the wrong answer. If that trade is acceptable, gc.reflogExpire is a one-line change, and the commit message should then say the fallback can still reject a correct push when the matching entry is older than the cutoff. Your call.

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.

Tyler Cipriani <tyler@tylercipriani.com> writes:

With a reflog that has never been expired, using all the available information will always work with better information than with cutoff, so that is not surprising at all ;-).

On 26-09-05 20:13:30, Aleksei Sviridkin wrote:

Code looks right to me with the date=0 fallback.

push.useForceIfIncludes is meant to tighten --force-with-lease's checks. Getting a wrong answer with advice telling me to pull would push me (pun intended) to drop the config and ditch the feature. For --force-if-includes, being wrong here is worse than being slow here.

Re: being slow. I tried to recreate some numbers from this thread with
my own test case using linux.git and 2k reflog entries. In the cases I
tried:

- With a commit-graph (which gc should write), walking + merge-base
   checks on 2k entries took 15ms. So a few microseconds per reflog entry
   roughly jibes with numbers from this thread.
- Without a commit-graph, each batched call to
   repo_in_merge_bases_many() walks the commit history from scratch:
   rejection took two minutes for 2k entries.

But my tests were artificial worst-case scenarios. And today, on my build, "date" already happens to be a low number. For folks like me, setting date=0 is a non-change and I've been unable to find any complaints of slowness on the mailing list (or by searching the web).

For folks where date happens to be a high number: this gets the feature working correctly. Bonus: doubling batch size after each call to repo_in_merge_bases_many took my 2min down to 10s, locally; a viable speed up if needed (but separate from this change).

The last paragraph of this log message is hard to read for me; I think people could come away from reading it with the wrong information.

Nits:

- The final paragraph of the log message starts with "The cut-off", but
   it's the first time you've used "cut-off." What cut-off?
- "an entry older than [...] is not expected to be the one being looked
   for" - passive voice, stacked verb phrases ("is not expected/to be"),
   and a subject separated from its verb by 9 words made this hard to
   follow. And it leaves questions: Why is <who or what> not looking at
   <what> entry?
- "Without a reflog" - which reflog? remote-tracking or local?
- Unclear referents:
     - "exactly that"
     - "that bound"

Problems (with more nits :)):

- "there is no such moment"
   - Readability: referring back to "moment" that came 23 words before
     this "moment" made me re-read this a few times.
   - Inaccuracy: there may have been a moment when the remote-tracking
     ref last moved, but there is no reliable record of it because there
     is no remote-tracking reflog. That is, someone may have removed the
     reflog, or the reflog could have been GC'd (neither case is
     mentioned in your message).
- Most importantly, since the way I parse it is technically incorrect:
   "the walk then reaches the oldest entry and falls back to the
   merge-base check...where the cut-off would have stopped it earlier." -
   Stopped what earlier? I read this sentence split on "where" (i.e., Y
   does this, whereas X does that).

   Read that way, the final sentence reads as:

   Walk without a cut-off:

   (a) "reaches the oldest entry"
   (b) "falls back to the merge-base check"

   vs.

   Walk with a cut-off: stops earlier and therefore does neither.

   But a walk with a cut-off falls back to a merge-base check, too. The
   difference is that without a cut-off you reach the oldest entry and
   therefore pass more local reflog entries to the merge-base check;
   i.e., potentially more calls to repo_in_merge_bases_many()

Tested: passes with the fix.

Without the fix it also passes on my machine. gdb says that the value of date is 2 for me (Linux x86_64, gcc (Debian 14.2.0-19) 14.2.0, on Trixie). To get the test to fail reliably, had to build with:

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

So, CI probably would miss date becoming uninitialized again. It also fails with a date set to a timestamp 90 days ago due, since test dates are 2005.

Minor nit: surrounding tests in t/t5533-push-cas.sh use setup_src_dup_dst, which would simplify the test setup.

I'd be happy to give a Reviewed-by once the log message is clearer.

Thanks.

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(-)

Aleksei Sviridkin <f@lex.la> writes:

Both changes look sensible. Thanks, Aleksei and Tyler, for writing and reviewing.

Will replace and mark it for 'next'.

Tyler Cipriani <tyler@tylercipriani.com> writes:

Thanks. Just FYI, the patch has textual conflicts in t5533 with your tc/push-force-if-includes-fixes topic, but the resolution was trivial.