On Tue, Jan 10, 2017 at 12:08 PM, Jacob Keller <jacob.keller@xxxxxxxxx> wrote: > On Mon, Jan 9, 2017 at 2:07 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> On Mon, Jan 9, 2017 at 10:44 AM, Jacob Keller <jacob.keller@xxxxxxxxx> 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