Mike Hommey <mh@xxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html