GIT_INDEX_FILE relative paths are relative to the work tree

GIT_INDEX_FILE relative paths are relative to the work tree

[Jack O'Connor]

When I use a relative path in the GIT_INDEX_FILE environment variable,
git interprets that path relative to the the work tree. This can be
confusing if my cwd is some subdirectory of my project; in that case
an index file is created in the project root rather than in my cwd. It
can also be confusing if I'm using --git-dir and --work-tree, in which
case the path is interpreted relative to the latter.

Is this behavior intentional? If so, I think it would be worth
mentioning in the documentation for GIT_INDEX_FILE. But I can't think
of a case where I would ever want an index file to end up inside my
work tree.

This also comes up in http://stackoverflow.com/a/7645492/823869. Using
absolute paths is a workaround.

Re: GIT_INDEX_FILE relative paths are relative to the work tree

[Duy Nguyen]

On Fri, Nov 27, 2015 at 4:17 PM, Jack O'Connor <oconnor663@gmail.com> wrote:
> When I use a relative path in the GIT_INDEX_FILE environment variable,
> git interprets that path relative to the the work tree. This can be
> confusing if my cwd is some subdirectory of my project; in that case
> an index file is created in the project root rather than in my cwd. It
> can also be confusing if I'm using --git-dir and --work-tree, in which
> case the path is interpreted relative to the latter.
>
> Is this behavior intentional? If so, I think it would be worth
> mentioning in the documentation for GIT_INDEX_FILE. But I can't think
> of a case where I would ever want an index file to end up inside my
> work tree.

It would be more intuitive if $GIT_INDEX_FILE is relative to user's
current directory, not some random work tree root. And mentioning it
as such is not sufficient, we may be able to access the index file
without a work tree. This variable is so old that I'm afraid changing
its behavior will break stuff, so probably best to document "relative
$GIT_INDEX_FILE is undefined behavior"

> This also comes up in http://stackoverflow.com/a/7645492/823869. Using
> absolute paths is a workaround.



-- 
Duy