Re: "git branch -f" corrupt other worktree

From: Duy Nguyen <pclouds@gmail.com>
Date: May 2, 2019, 13:05 UTC
Message-ID: <CACsJy8A67x5wtbTe9Zk6URLZOqMNUFaLuNyZSVdYkZ1Z3y=6+A@mail.gmail.com>
In-Reply-To: <87d0l1qat5.fsf@evledraar.gmail.com>

On Thu, May 2, 2019 at 7:51 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 56 quoted lines

>
>
> On Thu, May 02 2019, Duy Nguyen wrote:
>
> > 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".

I think it's a minefield to go with different views on refs. They can already have per-worktree refs now. Granted it's long to type (e.g. worktrees/foo/something) but it does help remind it's per-worktree. And we can probably improve the ref resolution rules to resolve "foo/something" (or "something" even) to worktrees/foo/something for example. But going totally custom, I think it's hard to even manage as a user.

With that said, I think we can technically support per-worktree refs even outside worktrees/, or the whole refeference space per-worktree, now. The difficulty will be coming up with some sane UI that can handle that and not leave too many traps behind. I can't see that UI.

-- 
Duy