Re: [long] worktree setup cases

[Nguyen Thai Ngoc Duy <pclouds@gmail.com>]

On Thu, Oct 21, 2010 at 4:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> There are a few factors that affect gitdir/worktree/cwd/prefix setup.
>> Those are:
>>
>>  - GIT_DIR (or --git-dir)
>>  - GIT_WORK_TREE (or --work-tree)
>>  - core.worktree
>>  - .git is a file pointing to real .git directory
>>  - Bare repo
>>
>> So there are 2^5 = 32 cases in total.
> Hmm, why is core.worktree separate from the second item?

It's how the code does it. GIT_WORK_TREE can be detected early, when
cwd has not been moved. When core.worktree is found, cwd could be
somewhere. I need to separate those cases to make sure cwd is not
misused after it's been moved.

> In any case, the
> three mechanisms to specify the working tree should only be in effect when
> GIT_DIR/--git-dir is used, so the above are not orthogonal, and the total
> count should be smaller than 32 cases.

Good to hear. I forgot that GIT_DIR must be set for the three
mechanisms in effect.

>> The following questions must be answered for each case:
>>
>> 0. What setup function handles that case?
>> 1. Is worktree available?
>> 2. Where is new cwd? Is it at worktree root?
>> 3. Prefix?
>> 4. Is (relative) $GIT_DIR accessible from current cwd?
>> 5. What if original cwd is outside worktree, or new cwd if it's not at
>>    worktree root?
>
> All good questions to ask, except for the last one which I cannot quite
> parse.

Skip "or new cwd... worktree root" part.

>> 1 Cases
>> ~~~~~~~~
>>
>> Case#  Bare  .git-file  core.worktree  GIT_DIR  GIT_WORK_TREE
>> 0      0     0          0              0        0
>> 8      0     1          0              0        0
>
> Ok.
>
>> 1      0     0          0              0        1
>> 4      0     0          1              0        0
>> 5      0     0          1              0        1
>> 9      0     1          0              0        1
>> 12     0     1          1              0        0
>> 13     0     1          1              0        1
>
> How does it make sense to have GIT_WORK_TREE without GIT_DIR?  Without
> GIT_DIR, we will run repository discovery, which means we will always go
> up to find a .git dir, and the reason for doing that is because we want to
> also work in a subdirectory of a working tree (the very original git never
> worked from anywhere other than the root level of the working tree).  By
> definition, the root of the working tree is the same as in cases 0/8.

OK.

>> 2      0     0          0              1        0
>> 10     0     1          0              1        0
>
> If you set GIT_DIR, we do no discovery, so git will work only from the
> root level of the working tree (or bare repository operation) if you do
> not tell us where the working tree is.

OK

>> 3      0     0          0              1        1
>> 6      0     0          1              1        0
>> 7      0     0          1              1        1
>> 11     0     1          0              1        1
>> 14     0     1          1              1        0
>> 15     0     1          1              1        1
>
> Without discovery, we know where the root level of the working tree is,
> and we know where the repository is, because you told us.  The answers to
> questions 1-5, i.e. semantics observable by the end user, should be the
> same as case 0/8 even though the internal codepath to achieve that,
> i.e. question 0, may be different.

OK too.

>> 16     1     0          0              0        0
>> ...
>> 31     1     1          1              1        1
>
> Shouldn't all of these 16 be the same, if the repository is bare?  What is
> your definition of bareness?  core.bare?  In any case we should say "you
> are using a bare repository, there is no working tree" and cwd shouldn't
> change in these cases.  They are all bare and there is no working tree.

Better this way. Although some sanity checks can be used. Like setting
core.bare and explicitly requesting worktree is insane.

> Alternatively, you could give precedence to core.worktree and friends, in
> which case these can go to the other categories in your description,
> ignoring core.bare settings.  For example, 31 explicitly specifies where
> the .git directory and the working tree are, which would fall into the
> same category as 3,6,7,11,14,15.

I don't want to ignore core.bare. If there are bare/worktree
conflicts, notify users. There are cases that a normal repo tends to
become a bare repo for just one operation. It's when "." is found a
repo, handled by setup_bare_git_dir(). In these cases, we might want
to consider core.worktree and friends again.

> Either way is fine.
-- 
Duy