Re: [PATCH/RFC 5/4] Redefine core.bare in multiple working tree setting

[Junio C Hamano <gitster@pobox.com>]

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

> With per-worktree configuration in place, core.bare is moved to main
> worktree's private config file. But it does not really make sense
> because this is about _repository_. Instead we could leave core.bare in
> the per-repo config and change/extend its definition from:
>
>    If true this repository is assumed to be 'bare' and has no working
>    directory associated with it.
>
> to
>
>    If true this repository is assumed to be 'bare' and has no _main_
>    working directory associated with it.
>
> In other words, linked worktrees are not covered by core.bare. This
> definition is the same as before when it comes to single worktree setup.

Up to this point, I think it is not _wrong_ per-se, but it does not
say anything about secondary worktrees.  Some may have their own
working tree, others may be bare, and there is no way for programs
to discover if a particular secondary worktree has or lacks its own
working tree.

Granted, "git worktree" porcelain may be incapable of creating a
secondary worktree without a working tree, but I think the
underlying repository layout still is capable of expressing such a
secondary worktree.

So there still is something else necessary, I suspect, to make the
definition complete.  Perhaps core.bare should be set in
per-worktree configuration for all worktrees including the primary
one, and made the definition/explanation of core.bare to be
"definition of this variable, if done, must be done in per-worktree
config file.  If set to true, the worktree is 'bare' and has no
working directory associated with it"?  That makes things even more
equal, as there is truly no "special one" at that point.

I dunno.