Jeff, you're doing crazy things beyond my (admittedly very limited) imagination :P I did not see this at all when I implemented the worktree stuff.
On Thu, Aug 23, 2018 at 8:21 PM Eric Sunshine <sunsh...@sunshineco.com> wrote: > > > In this case, it might make sense for "git worktree add" to refuse to > > > operate if an existing worktree entry still points at the directory > > > that you're trying to add. That should prevent those duplicate > > > worktree entries you saw. > > > > Yes, but then what's the next step for my script? I can't "remove" since > > the worktree isn't there. I can't blow away any directory that I know > > about, since there isn't one. > > I was thinking that "worktree add" could start respecting the --force > option as an escape hatch. > > > I need to somehow know that an existing > > "$GIT_DIR/worktrees/foo" is the problem. But "foo" is not even > > deterministic. Looking at the duplicates, it seems to be the basename of > > the working tree, but then mutated to avoid collisions with other > > worktrees. > > If the worktree directory still existed, "git -C rev-parse --git-dir" > inside the worktree would give you the proper path of > $GIT_DIR/worktrees/foo, but the directory doesn't exist, so... > nothing. > > > What about refusing by default, but forcing an overwrite with "-f"? > > My thought, also. Sounds good. Eric are you going to implement this? Just checking so that I can (hopefully) cross this off my backlog ;-) -- Duy
