Re: [RFC PATCH] builtin/worktree: enhance worktree removal

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Nov 21, 2017, 21:37 UTC
Message-ID: <CAPig+cQrC1MiPrwwPqtdX2tzj1ntFHxO28uqnMBcmVpPPrc_Rg@mail.gmail.com>
In-Reply-To: <20171121150954.3227-1-kaartic.sivaraam@gmail.com>

On Tue, Nov 21, 2017 at 10:09 AM, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 8 quoted lines

> The new feature to 'remove' worktree was handy to remove specific
> worktrees. It didn't cover one particular case of removal. Specifically,
> if there is an "entry" (a directory in <main_worktree>/.git/worktrees)
> for a worktree but the worktree repository itself does not exist then
> it means that the "entry" is stale and it could just be removed.
>
> So, in case there's a "worktree entry" but not "worktree direectory"
> then just remove the 'stale' entry.

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?

[1]: Excerpt from: https://public-inbox.org/git/CAPig+cTTrv2C7JLu1dr4+N8xo+7YQ+deiwLDA835wBGD6fhS1g@mail.gmail.com/

Other information which would be nice to display for each worktree [by the 'list' command] (possibly controlled by a --verbose flag):

   * the checked out branch or detached head
   * whether it is locked
        - the lock reason (if available)
        - and whether the worktree is currently accessible
    * whether it can be pruned
        - and the prune reason if so