Re: [PATCH v4 2/2] rev-parse: fix some options when executed from subpath of main tree

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

Mike Hommey <mh@glandium.org> writes:

> On Thu, May 26, 2016 at 07:19:16AM -0400, Michael Rappazzo 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, it can incorrectly
>> return a path which starts 'sub/path/.git'.  Change this to return the
>> proper relative path to the git directory.
>> 
>> Related tests marked to expect failure are updated to expect success
>
> As mentioned previously (but late in the thread), I don't get why this
> one case of --git-common-dir should not return the same thing as
> --git-dir, which is an absolute directory. Especially when there is
> other flag telling you whether you are in the main or another worktree,
> so comparing the output for --git-dir and --git-common-dir is the
> easiest way to do so, but then you have to normalize them on their own
> because git returns different values pointing to the same directory.

Sounds like a sensible line of thought.

A possible/plausible counter-argument from Michael's side that would
be equally sensible might run along the lines of:

    An expected use of "git rev-parse --commit-dir" is to store the
    output in $GIT_DIR/$X so that the layout the worktree machinery
    expects can be set up by scripted Porcelains without using "git
    worktree".  Making the value stored in $GIT_DIR/$X relative to
    $Y would help for such and such reasons.

While making it easier to build a competing UI like that is a
sensible goal, I do not think of what that $X or $Y are, and I do
not think of what that "such and such reasons" are, either.

And the cost of having to compare absolute --git-dir output with
relative --git-common-dir (i.e. the justification for Mike's
proposal to make --git-common-dir absolute) and the cost of having
to turn absolute output from --git-common-dir to a path relative to
$Y (i.e. the justification of making it relative in the hypothetical
counter-argument) would be about the same, so it does not sound very
compelling after all.