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

[Duy Nguyen <pclouds@gmail.com>]

On Tue, Mar 21, 2017 at 10:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

Yes I really want that, and even the ability to convert a normal one
repo (with one working tree) to the latter, moving the repository to
somewhere safe.

>>> 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"?

From $GIT_DIR perspective (which points to
$GIT_COMMON_DIR/worktrees/blah) then they do look like a repository
with lots of part borrowed from $GIT_COMMON_DIR. I was simply saying
I'm bad at naming things. "worktrees" is a better name than "repos".

> 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".
-- 
Duy