On 6/30/2022 12:44 PM, Junio C Hamano wrote: > Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: > >> 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. > > Either is fine by me. Other than this small glitch in the test, the > remainder of the "should we allow this branch to be touched?" topic > looked really cleanly done and ready to be unleashed to the public. If you don't mind, I've got some forward-fixes prepped for the next version of this topic. They are test-only changes and do not change the implementation of branch_checked_out(). One thing I noticed from looking back on the series is that I wrote a test that specifically tests a case that is impossible to construct without modifying the .git directory directly (having two worktrees "reserving" a branch for different reasons). That test will need to stay as one that knows about the internals of this storage, but the others can be replaced with more opaque steps. In patch 2 of this series, I test the 'update-refs' storage using a similar mechanism. I can replace that with the opaque version that calls 'git rebase --update-refs', but only as part of patch 7, since writing the file is not implemented yet. I was going to ask if I should reorder the patches, but there is a possibility that we will change the storage of these "reserved" refs yet again, so I won't focus on this point quite yet. Thanks, -Stolee
