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

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 21.03.2017 16:48:
> Duy Nguyen <pclouds@gmail.com> writes:
> 
>> On Tue, Mar 21, 2017 at 1:50 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> Junio C Hamano wrote:
>>>> Stefan Beller <sbeller@google.com> writes:
>>>
>>>>> 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).
>>>>
>>>> A more plausible situation is you start with a bare one as the
>>>> primary and used to make local clones to do your work in the world
>>>> before "git worktree".  It would be a natural extension to your
>>>> workflow to instead create worktrees of of that bare one as the
>>>> primary worktree with secondaries with working trees.
>>>
>>> For what it's worth, this conversation makes me think it was a mistake
>>> to call this construct a worktree.
>>
>> For the record, I am totally confused with Junio's last line, with two
>> "with"s, "worktree" and "working trees" in the same phrase :D
> 
> In case this wasn't just a tangential note, what I meant was:
> 
>  - In the old world, you may have had a single bare repository and
>    then made clones, each of which has a working tree (i.e. non-bare
>    clones), and worked inside these clones.
> 
>  - In the "git worktree" world, you can start from that same single
>    bare repository, but instead of cloning it, use "git worktree" to
>    create "worktree"s, each of which has a working tree, and work
>    inside these "worktree"s.
> 
> and the latter would be a natural extension to the workflow the
> former wanted to use.
> 
>>> It's fine for the command to have one name and the documentation to
>>> use a longer, clearer name to explain it.  What should that longer,
>>> clearer name be?
>>
>> No comments from me. I'll let you know that if Eric (or Junio?) didn't
>> stop me, we would have had $GIT_DIR/repos now instead of
>> $GIT_DIR/worktrees, just some extra confusion toppings.
> 
> I forgot about that part of the history, but you are saying you
> wanted to call these "repos", not "worktrees"?  I can see why
> somebody (or me?) would stop that by fearing "repo" is a bit too
> confusing with a "repository", in the same way that we are now
> realizing that "worktree" is too similar to an old synonym we used
> to call "working tree".
> 

I would say the new thing is really a "checkout", but that opens another
can of worms. On the other hand, "git checkout" already does:
- switching of branches
- creation of branches
- detaching of head
- partial updates of the working tree
So why shouldn't it manage worktrees, as well?

While that may sound a bit sarcastic it indicates that we may want to
rethink some things at some point rather than adding up to the
conflation. The discussion in this thread seems to show that "worktree"
is just as a good a name for the new feature, while "workbase" or
"workroot" (or "workdir") or so could have been for the old one.

Are we at a point where we can still rename the new feature at least? If
yes, and keeping everything else is mandatory, than "workspace" or
"working space" may be a serious contender for naming the new thing.

Michael