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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Aug 24, 2018, 22:55 UTC
Message-ID: <CAPig+cQNkMEUj=6e=6czbkWeozJQ-Go09C6bZwVJUTpM3JJiiw@mail.gmail.com>
In-Reply-To: <CACsJy8BxxyRxqCj5ZoOmPaiwmFRKHU72yTxyC_eHXS+cEa94zw@mail.gmail.com>

On Fri, Aug 24, 2018 at 10:47 AM Duy Nguyen <pclouds@gmail.com> wrote:

Show 15 quoted lines

> On Thu, Aug 23, 2018 at 8:21 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > Peff wrote:
> > > 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.
> >
> > > 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 ;-)

It wasn't something I was planning on working on (at least not immediately) since it's still a bit fuzzy for me whether this is enough to help Peff's use-case (and because I have several other things in my queue, already).

However, before even considering implementing it, there's at least one question (and possibly others) needing answering. For instance, how should "add --force" interact with a locked (not-present) worktree? Should it blast it despite the lock? Or would that need --force specified twice ("git worktree add -f -f foo")?

As for the actual implementation, I haven't yet looked at how much surgery will be needed to make 'add' respect --force.