On Tue, Aug 21, 2018 at 4:43 PM Jeff King <peff@xxxxxxxx> wrote: > 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@xxxxxxxx> 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. > > 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. > > 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.
