From: Aleksei Sviridkin <f@lex.la>
To: git@vger.kernel.org
Cc: Aleksei Sviridkin <f@lex.la>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2] push: fix --force-if-includes when remote-tracking ref has no reflog
Date: Sun, 6 Sep 2026 19:50:52 +0300 [thread overview]
Message-ID: <20260906165052.21780-1-f@lex.la> (raw)
In-Reply-To: <xmqq33vn5hsq.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> 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.
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.
next prev parent reply other threads:[~2026-09-06 16:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 1:05 [PATCH] push: fix --force-if-includes when remote-tracking ref has no reflog Aleksei Sviridkin
2026-09-03 16:16 ` Junio C Hamano
2026-09-03 20:00 ` Aleksei Sviridkin
2026-09-03 20:11 ` Junio C Hamano
2026-09-03 21:45 ` Aleksei Sviridkin
2026-09-04 1:03 ` Kristoffer Haugsbakk
2026-09-04 16:48 ` Junio C Hamano
2026-09-05 17:13 ` Aleksei Sviridkin
2026-09-06 9:39 ` Kristoffer Haugsbakk
2026-09-06 17:14 ` Junio C Hamano
2026-09-07 4:54 ` Thomas Bachem
2026-09-07 6:23 ` Weijie Yuan
2026-09-04 12:44 ` [PATCH v2] " Aleksei Sviridkin
2026-09-04 15:42 ` Junio C Hamano
2026-09-06 0:45 ` Junio C Hamano
2026-09-06 16:50 ` Aleksei Sviridkin [this message]
2026-09-08 3:47 ` Junio C Hamano
2026-09-09 6:56 ` Aleksei Sviridkin
2026-09-10 0:57 ` Junio C Hamano
2026-09-10 8:31 ` Aleksei Sviridkin
2026-09-05 17:13 ` [PATCH v3] " Aleksei Sviridkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260906165052.21780-1-f@lex.la \
--to=f@lex.la \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).