Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> Can patch 3/3 be split into two, > > I actually don't think so. The `refs_resolve_unsafe()` function simply > ... > In other words, a fix for one bug would be a fix for the other, and > (probably) vice versa. What mislead me was the way this step presented itself. It sounded as if the primary (and possibly the only) thing the series wanted to fix was to make .denyCurrentBranch pay attention to other worktrees, and while fixing that, it broke as collateral damage a "feature" that denyCurrentBranch allows an unborn branch to be updated no matter what and called it a bugfix when it was not a bug. If the series is fixing two bugs, perhaps 2/3 can first fix it for a primary worktree case by seeing what HEAD symref for the primary worktree points at is the target of a push without iterating over all the worktrees, have the test change in 2/3 (i.e. "fixing the 'unborn' case revealed a wrong expectation in an existing test"), and a couple of new tests to see what a push from sideways would do to an unborn branch that is checked out in the primary worktree when .denyCurrentBranch is and isn't in effect. Then 3/3 can use the same logic to see if one worktree is OK with the proposed ref update by the push used in 2/3 (which no longer uses refs_resolve_unsafe()') to check for all worktrees. The new tests introduced in 2/3 would be extended to see what happens when the unborn branch getting updated by the push happens to be checked out in a secondary worktree. That would have avoided misleading this reader. Thanks.
