On Tue, Nov 21, 2017 at 9:12 PM, Junio C Hamano <gits...@pobox.com> wrote: > Eric Sunshine <sunsh...@sunshineco.com> writes: >> Let me see if I understand. Sometimes you know that you've deleted the >> worktree directory, in which case 'git worktree prune' is the obvious >> choice. However, there may be cases when you've forgotten that you >> deleted the worktree directory (or it got deleted some other way), yet >> it still shows up in "git worktree list" output with no indication >> that it has been deleted (though, ideally, it should tell you so[1]). >> In this case, you see a worktree that you know you no longer want, so >> you invoke "git worktree remove" but that errors out because the >> actual directory is already gone. This patch make the operation >> succeed, despite the missing directory. Is that correct? > > Hmph, so the user could be using "git worktree prune" after seeing > the error? Was there a reason behind "git worktree remove" to be > extra careful to make sure both existed before going forward, or was > this a simple oversight?
The erroring out in this case looks like simple oversight. Most likely, this particular case did not occur to Duy. The code does intentionally check the directory to see if it is dirty so that it can warn the user (in which case the user can re-run with --force or take other corrective action), but erroring out if the directory is merely an indirect (and unintended) result of trying to check for dirtiness. So, Kaatic's patch is intended to address that oversight (though I haven't examined the implementation closely; I was just trying to understand the reason for the patch).
