On 6/28/22 4:44 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: >> -test_expect_success 'refuse to overwrite: worktree in rebase' ' >> +test_expect_success 'refuse to overwrite: worktree in rebase (apply)' ' >> + test_when_finished rm -rf .git/worktrees/wt-*/rebase-apply && >> + >> + mkdir -p .git/worktrees/wt-3/rebase-apply && >> + echo refs/heads/fake-1 >.git/worktrees/wt-3/rebase-apply/head-name && >> + echo refs/heads/fake-2 >.git/worktrees/wt-3/rebase-apply/onto && >> + >> + test_must_fail git branch -f fake-1 HEAD 2>err && >> + grep "cannot force update the branch '\''fake-1'\'' checked out at.*wt-3" err >> +' >> + >> +test_expect_success 'refuse to overwrite: worktree in rebase (merge)' ' >> test_when_finished rm -rf .git/worktrees/wt-*/rebase-merge && >> >> mkdir -p .git/worktrees/wt-3/rebase-merge && > > This is not the first offender, since the other existing one is > doing the same, but it is a bit sad that this makes it worse to > expose and depend on the details of the way the rebase happens to be > currently implemented. This is true that it is based on how it's currently implemented. I was confused that none of these rebase storage mechanisms are documented anywhere (so I couldn't extend that documentation with the new update-refs file added in this series). But perhaps that's by design: this is intentionally an internal implementation detail. I do wonder where that leaves third-party implementations like libgit2 to handle any changes we make in this space, or how much we care about supporting someone rebasing in a worktree with an older Git client while also checking out a branch in another worktree using a newer one. > Perhaps a more kosher way to do this is to find an commit that > surely would not allow fake-1 branch to be cleanly rebased onto and > actually start (and cause it to stop) a rebase. This, and the equivalent "pause in the middle of a bisect" would be ways to hide these internal details. While I was thinking that this provides a low-weight mechanism for testing the implementation of branch_checked_out(), it is only testing the implementation but not the _intention_. If 'git rebase' changed its backend, then these tests would not start failing as we need them to. > I notice that the original offence was committed fairly recently, by > d2ba271a (branch: check for bisects and rebases, 2022-06-14) that we > can easily eject out of the 'next' branch when we rewind and rebuild > it, if we wanted to. I can either re-roll that series or create a new forward-fix that includes the functionality of this test. Both are the same amount of work for me, so let me know which you prefer. Thanks, -Stolee
