Re: [PATCH v3 18/25] setup.c: support multi-checkout repo setup

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

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

> The repo setup procedure is updated to detect $GIT_DIR/commondir and
> set $GIT_COMMON_DIR properly.
>
> The core.worktree is ignored when $GIT_DIR/commondir presents. This is
> because "commondir" repos are intended for separate/linked checkouts
> and pointing them back to a fixed core.worktree just does not make
> sense.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>  Documentation/config.txt        |  3 +-
>  Documentation/git-rev-parse.txt |  3 ++
>  builtin/rev-parse.c             |  4 +++
>  cache.h                         |  1 +
>  environment.c                   |  8 ++---
>  setup.c                         | 33 +++++++++++++-----
>  t/t1501-worktree.sh             | 76 +++++++++++++++++++++++++++++++++++++++++
>  t/t1510-repo-setup.sh           |  1 +
>  trace.c                         |  1 +
>  9 files changed, 115 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 5f4d793..cbf4d97 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -381,7 +381,8 @@ false), while all other repositories are assumed to be bare (bare
>  
>  core.worktree::
>  	Set the path to the root of the working tree.
> -	This can be overridden by the GIT_WORK_TREE environment
> +	This can be overridden by the GIT_WORK_TREE
> +	or GIT_COMMON_DIR environment
>  	variable and the '--work-tree' command line option.

During my first reading, I was guessing that the reason you changed
this is because COMMON_DIR may redirect the config file from which
core.worktree may be read.  But that is probably not what you meant.
You do not want to share core.worktree between the borrowing and the
borrowed repositories.  If the presense of GIT_COMMON_DIR _disables_
core.worktree settings without supplying an alternative value, as
opposed to GIT_WORK_TREE which does override with an alternative
value, it is very different from "can be overriden".

It needs a better phrasing.

By the way, do we need to do something special for core.bare as
well for a similar reason?