On Fri, Mar 17, 2017 at 6:36 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> -List details of each worktree. The main worktree is listed first, followed by >> -each of the linked worktrees. The output details include if the worktree is >> -bare, the revision currently checked out, and the branch currently checked out >> -(or 'detached HEAD' if none). >> +List details of each working tree. The main working tree is listed first, >> +followed by each of the linked working trees. The output details include if >> +the working tree is bare, the revision currently checked out, and the branch >> +currently checked out (or 'detached HEAD' if none). > > I do not think this is correct. > > Think of a "worktree" something that roughly corresponds to > different location you can refer to with $GIT_DIR. > > A $GIT_DIR may be a true repository. Or it may be borrowing many of > the things from its primary repository. Even though "git worktree" > Porcelain may not currently be equipped to create a "bare" $GIT_DIR, > there is no fundamental reason that a secondary "worktree" must have > a working tree, i.e. a "worktree" could be a "bare" one (it would be > the first use of per-worktree config; a secondary worktree that is a > bare can be made by borrowing from the primary worktree that has a > working tree). While it may be true that you can have bare worktrees; I would question why anyone wants to do this, as the only thing it provides is an additional HEAD (plus its reflog). > Now, what does "git worktree list" enumearate? It does not list > "working trees"; its output are list of things, each of which you > could point at with $GIT_DIR and work with. $ git worktree list /.../git 0b47ebba82 [status-short] /.../git_origin_master 5588dbffbd (detached HEAD) /.../submodule_remote_dot 3d9025bd69 (detached HEAD) This looks to me as if it is listing actual working trees. But looking at the actual code, I confirm we list worktrees here, even bare worktrees are taken care of. That said, "worktree prune" (as well as (un)lock) are operating on "worktrees" as you defined above: $ git worktree add test $ git worktree list # see the "test" worktree listed by its working tree rm -rf test # remove the working tree attached to the test worktree $ git worktree list # see the "test" worktree listed by its working tree, still there $ git worktree prune $ git worktree list # the "test" worktree is gone. So maybe we need a patch that is s/working tree/worktree/ in the prune section? Thanks, Stefan