Re: [PATCH] Documentation/git-worktree: use working tree for trees on the file system

On Fri, Mar 17, 2017 at 6:36 PM, Junio C Hamano [off-list ref] wrote:

Stefan Beller [off-list ref] writes:

quoted

-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