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

From: Stefan Beller <sbeller@google.com>
Date: Mar 20, 2017, 17:29 UTC
Message-ID: <CAGZ79kayeSxFTJr3Q1atFgOyR74PzQyCLiejuZxh7+wTGGb=ww@mail.gmail.com>
In-Reply-To: <xmqq60j75psk.fsf@gitster.mtv.corp.google.com>

On Fri, Mar 17, 2017 at 6:36 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 24 quoted lines

> Stefan Beller <sbeller@google.com> 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