Re: [PATCH v2 1/4] rev-parse: fix some options when executed from subpath of main tree

From: SZEDER Gábor <szeder@ira.uka.de>
Date: May 6, 2016, 14:13 UTC
Message-ID: <20160506161312.Horde.7i8_sE5ISIqccneOIfinvCX@webmail.informatik.kit.edu>
In-Reply-To: <CANoM8SWBzFiHGc3zAwndyx+GUkWQGDoaewVVQtH-06jazAn8uQ@mail.gmail.com>

Quoting Mike Rappazzo <rappazzo@gmail.com>:

Show 20 quoted lines

> On Fri, Apr 29, 2016 at 9:50 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>>> Executing `git-rev-parse` with `--git-common-dir`, `--git-path <path>`,
>>> or `--shared-index-path` from the root of the main worktree results in
>>> a relative path to the git dir.
>>>
>>> When executed from a subdirectory of the main tree, however, it incorrectly
>>> returns a path which starts 'sub/path/.git'.
>>
>> This is not completely true, because '--git-path ...' returns a
>> relative path starting with '.git':
>>
>>  $ git -C t/ rev-parse --git-dir --git-path objects --git-common-dir
>>  /home/szeder/src/git/.git
>>  .git/objects
>>  t/.git
>>
>> It's still wrong, of course.
>
> I'll try to reword this to make it indicate that the value isn't
> always incorrect.

Not sure I understand your intention about rewording, in particular that "isn't always incorrect" part. Just to make sure there is no misunderstanding let's have a look at the two broken cases:

    $ git -C t/ rev-parse --git-common-dir
    t/.git

Obviously wrong. This is what you correctly described in the commit message as "incorrectly returns a path which starts 'sub/path/.git'.

    $ git -C t/ rev-parse --git-path objects
    .git/objects

Wrong as well. It would be correct if we were at the top of the working tree, but we are not. It must be relative to the directory where '-C t/' brought us. Your description in the commit message implies that '--git-path <path>' is wrong in the same way as '--git-common-dir' is, i.e. in this case would also return the relative path starting with the subdirectory. That is apparently not the case.

My point in the previous email was that both are wrong when executed in a subdir of the working tree, but they are wrong in different ways. And they are always wrong when executed from a subdir of the working tree. I would have described the current wrong behavior as:

    When executed from a subdirectory of the working tree, however,
    '--git-common-dir' incorrectly returns a path which starts
    'sub/path/.git', while '--git-path <path>' incorrectly returns a path
    relative to the top of the working tree.

(Still hasn't looked at shared index...)

Show 17 quoted lines

>>> Change this to return the
>>> proper relative path to the git directory.
>>
>> I think returning absolute paths would be better.  It is consistent
>> with the already properly working '--git-dir' option, which returns an
>> absolute path in this case.  Furthermore, both '--git-path ...' and
>> '--git-common-dir' already return absolute paths when run from a
>> subdirectory of the .git directory:
>>
>>  $ git -C .git/refs rev-parse --git-dir --git-path objects --git-common-dir
>>  /home/szeder/src/git/.git
>>  /home/szeder/src/git/.git/objects
>>  /home/szeder/src/git/.git
>>
>
> I agree with this, but at one point Junio suggested that it should
> return the relative path[1],

I wasn't aware of Junio's suggestion.

It shouldn't really matter in practice, because both the absolute and relative paths will ultimately lead to the same place. However, I still think that for consistency's sake absolute paths would be better when executed in a subdir of the working tree.