On Thu, May 2, 2019 at 7:51 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > On Thu, May 02 2019, Duy Nguyen wrote: > > > On Thu, May 2, 2019 at 6:59 PM frank kulow <kulow.f@xxxxxxxxxxxxxx> 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
