On Fri, Aug 24, 2018 at 06:55:24PM -0400, Eric Sunshine wrote:
> On Fri, Aug 24, 2018 at 10:47 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> > On Thu, Aug 23, 2018 at 8:21 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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).
I'm pretty sure it would just be a one-liner to "worktree add -f" in the
doc-diff script. So I think it does solve the problem.
> 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")?
Yes, I think that should probably be two forces.
> As for the actual implementation, I haven't yet looked at how much
> surgery will be needed to make 'add' respect --force.
Me either. I may take a look this weekend. I got sucked into an asm and
coccinelle rabbit hole the last few days.
-Peff
