Re: worktree duplicates, was: [PATCH] SubmittingPatches: mention doc-diff

[Duy Nguyen <pclouds@gmail.com>]

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 <sunshine@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