Re: "git branch -f" corrupt other worktree
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- May 2, 2019, 13:49 UTC
- Message-ID
- <CACsJy8CzakrDS8qW5DTbkG_SNaVQ7Y6Ps-vT91zRPKGgvUUQeA@mail.gmail.com>
- In-Reply-To
- <CACsJy8A67x5wtbTe9Zk6URLZOqMNUFaLuNyZSVdYkZ1Z3y=6+A@mail.gmail.com>
On Thu, May 2, 2019 at 8:05 PM Duy Nguyen <pclouds@gmail.com> wrote:
Show 16 quoted lines
> > 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.
Correction (apparently I'm not using per-worktree refs enough to remember).
s,worktrees/foo/something,worktree/something,
worktrees/<name>/<ref> is to access per-worktree refs of other worktrees. worktree/<ref> is about the current one.
Show 11 quoted lines
> 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
-- Duy