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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 12, 2017, 23:08 UTC
Message-ID: <xmqqh953j2q0.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170110113320.13119-1-pclouds@gmail.com>

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

Show 15 quoted lines

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