I'm trying to understand some confusing behavior with the interaction of the situations mentioned in the subject line—in particular, I'm trying to figure out if this is expected behavior and what I can do to ease my own pain when I occasionally have reason for the following workflow: - Colleague pushes a branch; it needs some help to get merged, which they don't have time for. I do. - After "git fetch," since the cleanups are small, I "git switch --detach origin/their-branch" - Hack hack; "git commit --amend" or some other history-rewriting command (e.g., also "git rebase origin" while I'm at it) - (after copying the range-diff) "git pf origin @:refs/heads/their-branch" Now, "pf" is an alias for "push --force --force-with-lease" (what I think of as "safer force push"), and I have "push.useForceIfIncludes = true" set globally. I'm _expecting_ Git to push, since the remote-tracking branch I'd be updating hasn't changed. Instead, I get a "remote ref updated since checkout" rejection complete with advice about the tip having changed. But the tip hasn't actually changed, which I'm able to verify in several ways. While writing this mail, it occurred to me that maybe the issue is that the reflog behavior from --force-if-includes doesn't work in detached HEAD mode? At any rate, doing "git pf --force-with-lease=their-branch:$(git rev-parse origin/their-branch) origin @:refs/heads/their-branch" works, but omitting the right-hand-side of the lease doesn't. Should I stop using force-if-includes when in detached HEAD (aka, start passing "--no-force-if-includes" in those rare circumstances)? Or is there a shorter way to get where I want to go here? -- D. Ben Knoble
