Re: "git branch -f" corrupt other worktree

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 2, 2019, 12:51 UTC
Message-ID: <87d0l1qat5.fsf@evledraar.gmail.com>
In-Reply-To: <CACsJy8CJ_PB+QKp-T-yTHNPYgjEEVN39QbnAu4kKzGGcEQ0ezA@mail.gmail.com>

On Thu, May 02 2019, Duy Nguyen wrote:

Show 39 quoted lines

> On Thu, May 2, 2019 at 6:59 PM frank kulow <kulow.f@googlemail.com> wrote:
>>
>> git version 2.21.0.windows.1
>>
>> > /c/tmp/gt (Branch_702091a0)
>> $ git worktree add ../wt master
>> Preparing worktree (checking out 'master')
>> HEAD is now at f534c32 4
>>
>> > /c/tmp/gt (Branch_702091a0)
>> $ git branch -D master
>> error: Cannot delete branch 'master' checked out at 'C:/tmp/wt'
>>
>> #but this is possible:
>>
>> > /c/tmp/gt (Branch_702091a0)
>> $ git branch -f master HEAD
>
> I admit I didn't see this. But I don't know how far we would go
> protecting other worktrees. You give --force and that usually means
> "Yes I know what I'm doing, don't stop me". If --force rejects in this
> case, what would be the real force, --force --force maybe, or fall
> back to "git update-ref"?
>
>>
>> #and the other worktree is now corrupted:
>>
>> > /c/tmp/wt (master)
>> $ git status
>> On branch master
>> Changes to be committed:
>>   (use "git reset HEAD <file>..." to unstage)
>>
>>         modified:   txt.txt
>>         deleted:    txtb.txt
>>
>>
>>
>> greetings f.kulow

Part of this is "doctor, it hurts when I stab my eye" :) but I wonder in general whether users are more likely to expect different worktrees to have different views of the refstore, since they way they're created is "I want just this branch over there".

I.e. whether they want something closer to another directory with "alternates" pointing to the "main" repo, and whether that should be promoted to UI that's easier to set up than it is now.

Or maybe something in-between, where they'd expect remote tracking refs to update for everything, but a worktree's "master" branch not to be touchable by a worktree on "topic".