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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Aug 23, 2018, 18:19 UTC
Message-ID: <CAPig+cTghgbBo5VfZN+VP2VM00nPkhUqm0dOUqO37arxraxBKw@mail.gmail.com>
In-Reply-To: <20180821204341.GA24431@sigill.intra.peff.net>

On Tue, Aug 21, 2018 at 4:43 PM Jeff King <peff@peff.net> wrote:

Show 8 quoted lines

> On Tue, Aug 21, 2018 at 04:22:08PM -0400, Eric Sunshine wrote:
> > On Tue, Aug 21, 2018 at 3:36 PM Jeff King <peff@peff.net> wrote:
> > How about using "git clone --shared" instead?
>
> That seems even more dangerous to me, since the created clone can become
> corrupt when the parent prunes. Probably not huge for a single
> operation, but you may be surprised when you run the script a few days
> later and it barfs horribly due to a missing object.

Okay. I had thought that doc-diff was never doing anything other than read-only operations on the checked-out worktree after the initial creation, but, looking more closely at the script, I now see that it can perform other Git-based operations, so what you say makes sense.

Show 11 quoted lines

> > In the case that you've already blown away the directory, then having
> > "git worktree add" prune away the old worktree bookkeeping would make
> > sense and wouldn't lose anything (you've already thrown it away
> > manually). However, it could be lossy for the case when the directory
> > is only temporarily missing (because it's on removable media or a
> > network share).
>
> I think the removable ones already suffer from that problem (an auto-gc
> can prune them). And they should already be marked with "git worktree
> lock". That said, people don't always do what they should, and I'd
> rather not make the problem worse. :)

Hmph. I thought that "git worktree prune" had a sensible "expire" default to protect against such cases of removable media for which "git worktree lock" wasn't invoked, but, looking at the code, I see that the default is TIME_MAX.

Show 8 quoted lines

> > 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.

Show 5 quoted lines

> 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.