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

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.