Re: git branch -D doesn't work with deleted worktree
On Tue, Jan 10, 2017 at 12:08 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
Show 19 quoted lines
> On Mon, Jan 9, 2017 at 2:07 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Mon, Jan 9, 2017 at 10:44 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>>> Why not just update the documentation to be "when you are done with a
>>> work tree you can delete it and then run git worktree prune"?
>>
>> The document does say that (a bit verbose though):
>>
>> When you are done with a linked working tree you can simply delete it.
>> The working tree's administrative files in the repository (see
>> "DETAILS" below) will eventually be removed automatically (see
>> `gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run
>> `git worktree prune` in the main or any linked working tree to
>> clean up any stale administrative files.
>> --
>> Duy
>
> Right, so maybe we can make it more clear since it's not quite as
> simple as "deleting the work tree" because of stuff like stale
> branches..
Patches are welcome. I wrote that paragraph and you could clearly see its "quality" (from user perspective).
> or would it be worth re-scanning worktrees when we do
> branch deletion? (obviously ignoring the ones that are marked as on
> removable media)
Probably. We run "git worktree prune" as part of "git gc" and that command is automatically called in a couple places. Adding another "git gc" here probably does not hurt. However it could trigger a full repack and make "git branch" hang for a few seconds...
And no I don't want to single out "git worktree prune" to be called in git-branch. We should either go through git-gc or none. We could check if a worktree is deleted and suggest the user to run "git gc" though, but it's getting too complicated when "git worktree remove" will soon be the recommended way of deleting a worktree. So.. I don't know..
--
Duy