Re: [PATCH v6 0/3] push: check pushed ref for --force-if-includes

[Tyler Cipriani <tyler@tylercipriani.com>]

Adding Patrick to CC, like I should've from v4 onwards. Whoops!

Patrick: to address your review, since v4, I no longer special-case HEAD
(as in v3), and, instead, resolve any passed source ref. Now, if the
source ref resolves to a branch, we check that branch's reflog for the
remote tip. But for any other source (e.g., tag, oid, detached HEAD), I
reject the push as unverifiable. I'd value your opinion on whether that
matches up with what you meant.

I'm rejecting anything other than a branch reflog as "unverifiable" as
other reflogs fail to record the integration info we need for
--force-if-includes. HEAD's reflog spans all branches (rejected in the
OG review, c. 2020), tag reflogs (when they exist) record where the tag
pointed. And while a source tag/oid may be the same oid as the tip of a
branch, using that to map a tag/oid to a branch seems specious: many
branches could point to the same commit with no way to say which
branch's reflog to check.

Ben and I have talked a bit about the consequences of rejecting
non-branch pushes with --force-if-includes, viz: it breaks workflows
that give the appearance of working today. For example, pushing
<tag>:hotfix is allowed today (if you have a local "hotfix" branch whose
reflog looks right), but --force-if-includes has never checked anything
about the tag. 3/3 lets fast-forward, non-branch pushes through; 2/3's
advice points to --force-with-lease=<ref>:<expect> for the rest.

Very interested in others' opinions about this tradeoff.

Note: Junio flagged a trivial textual conflict in t5533 with
as/push-force-if-includes-no-reflog: both topics add tests after the
same existing test.

There's a small conflict against the tip of maint now, too. a85a43c480
(push: suggest <remote> <branch> for a slash slip, 2026-06-27) adds some
advice that sorts alphabetically after my 2/3. Happy to send a rebased
v7 if that's helpful.

Thanks.