On February 20, 2018 5:22 PM Eric Sunshine wrote: > On Tue, Feb 20, 2018 at 3:36 PM, Randall S. Becker > <rsbecker@xxxxxxxxxxxxx> wrote: > > I’m a bit confused about this, as I thought I understood worktrees :(. > > > > /home/randall/nsgit/test/test dir.mytest: rm -rf dest.wt > > /home/randall/nsgit/test/test dir.mytest/dest: git worktree prune -v > > Removing worktrees/dest.wt: gitdir file points to non-existent > > location > > > > It seems like one or two situations are a problem: > > 1) I’m using a full path for the worktree. > > 2) There’s a blank in my path – deliberate… tests, yanno. > > > > This is git 2.16.2. Could anyone shed some light on this? > > This appears to be working as intended. "git worktree prune" is telling you > that it is pruning the administrative data for the "dest.wt" worktree (reason: > "worktree location no longer exists"), which you intentionally deleted before > pruning. It's not clear what it is that you find confusing. There is not a lot > more I can say without understanding what behavior you were expecting > and how your expectation differs from the actual experience. I should have been more clear here as to the issue. My bad. The git worktree prune operation does not remove all vestiges of the removed worktree. The following files are retained: ./logs/refs/heads/dest.wt ./refs/heads/dest.wt So, now that I understand in hindsight, these are actually references to the worktree branch 'dest.wt' that obviously remains correctly and properly in git. Adding: git branch -D dest.wt to my test script cleared my (embarrassing) problem of my own doing. > > (Also, please consider how easy or difficult it is for a reader to interpret your > pasted "sample session". The one provided is more confusing than necessary > due to the command prompt bearing the same path information as the > output of the "git worktree list" command, as well as unnecessary duplicated > commands, such as "ls", and missing "cd" commands which do not help to > illuminate what it is you are trying to get across. The pasted transcript also > contains invalid code-points which render as oddball characters -- or not at all > -- which didn't help. Best would be to prepare a minimal example of shell > commands to reproduce the behavior you're trying to illustrate.) Good point. Again, my bad - very long day debugging. I wanted to show where I was in the directory so I sacrificed brevity for completeness and noise. My apologies. So, no bug, just a buggy user. Cheers, Randall
