GIT_INDEX_FILE relative path breaks in subdir

GIT_INDEX_FILE relative path breaks in subdir

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

joey@darkstar:/tmp>git init test
Initialized empty Git repository in /tmp/test/.git/
joey@darkstar:/tmp>cd test
joey@darkstar:/tmp/test>mkdir sub
joey@darkstar:/tmp/test>cd sub
joey@darkstar:/tmp/test/sub>GIT_INDEX_FILE=../.git/otherindex git write-tree
fatal: Unable to create '/tmp/test/../.git/otherindex.lock': No such file or directory

Appears to be a bug in git. Seems that it's assuming GIT_INDEX_FILE is
relative to the top of the worktree and not to the CWD.

Workaround: Use absolute path to the index file.

joey@darkstar:/tmp/test/sub>GIT_INDEX_FILE=`pwd`/../.git/otherindex git write-tree
4b825dc642cb6eb9a060e54bf8d69288fbee4904
joey@darkstar:/tmp/test/sub>ls ../.git/otherindex 
../.git/otherindex

git version 2.8.1

-- 
see shy jo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: GIT_INDEX_FILE relative path breaks in subdir

[Junio C Hamano]

Joey Hess <id@joeyh.name> writes:

> Appears to be a bug in git. Seems that it's assuming GIT_INDEX_FILE is
> relative to the top of the worktree and not to the CWD.

I think that has always been the case.  You can always specify it as
relative to the top.  Of course, you can use absolute.

Re: GIT_INDEX_FILE relative path breaks in subdir

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

Junio C Hamano wrote:
> Joey Hess <id@joeyh.name> writes:
> 
> > Appears to be a bug in git. Seems that it's assuming GIT_INDEX_FILE is
> > relative to the top of the worktree and not to the CWD.
> 
> I think that has always been the case.  You can always specify it as
> relative to the top.  Of course, you can use absolute.

I think it *has* always been that way, but is there anything in the
documentation that indicates this is the case? This could well be best
fixed in the documentation.

Hmm, at least GIT_OBJECT_DIRECTORY also behaves this way.
(OTOH, GIT_DIR does not behave this way).

-- 
see shy jo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: GIT_INDEX_FILE relative path breaks in subdir

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]

This is actually worse than I thought; when git is being run with a
detached work tree, GIT_INDEX_FILE is treated as a path relative to CWD,
instead of the normal behavior of relative the top of the work tree.

Normal and expected (according to this thread anyway):

joey@darkstar:~/src/other/git/Documentation> input="100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1    frotz"
joey@darkstar:~/src/other/git/Documentation> echo "$input" | GIT_INDEX_FILE=.git/newindex git update-index --index-info 
joey@darkstar:~/src/other/git/Documentation> ls ../.git/newindex 
../.git/newindex

Fully detached worktree and git dir:

joey@darkstar:/> echo "$input" | GIT_INDEX_FILE=.git/index git --git-dir=/home/joey/src/other/git/.git --work-tree=/home/joey/src/other/git update-index --index-info 
fatal: Unable to create '/.git/index.lock': No such file or directory
joey@darkstar:/> echo "$input" | GIT_WORK_TREE=/home/joey/src/other/git GIT_DIR=/home/joey/src/other/git/.git GIT_INDEX_FILE=.git/newindex git update-index --index-info 
fatal: Unable to create '/.git/newindex.lock': No such file or directory

Work tree detached via git configuration:

joey@darkstar:~/src/other/git> git config core.worktree /home/joey/src/other/git/tmptree
joey@darkstar:~/src/other/git> mkdir tmptree
joey@darkstar:~/src/other/git> cd tmptree/
joey@darkstar:~/src/other/git/tmptree> mkdir Documentation
joey@darkstar:~/src/other/git/tmptree> cd Documentation/
joey@darkstar:~/src/other/git/tmptree/Documentation> echo "$input" | GIT_INDEX_FILE=.git/index git update-index --index-info
fatal: Unable to create '/home/joey/src/other/git/tmptree/.git/index.lock': No such file or directory

This seems to make it basically impossible for any program that wants to
use GIT_INDEX_FILE to use anything other than an absolute path;
there are too many configurations to keep straight that could change how
git interprets what should be a simple relative path to a file.

-- 
see shy jo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: GIT_INDEX_FILE relative path breaks in subdir

[Junio C Hamano]

Joey Hess <id@joeyh.name> writes:

> This seems to make it basically impossible for any program that wants to
> use GIT_INDEX_FILE to use anything other than an absolute path;
> there are too many configurations to keep straight that could change how
> git interprets what should be a simple relative path to a file.

Thanks for digging.  Perhaps this needs to be documented (not "in
this case it is take as relative to that, in this other case, ...",
but "you cannot rely on relative being relative to something you
think").

Re: GIT_INDEX_FILE relative path breaks in subdir

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

Junio C Hamano wrote:
> Joey Hess <id@joeyh.name> writes:
> 
> > This seems to make it basically impossible for any program that wants to
> > use GIT_INDEX_FILE to use anything other than an absolute path;
> > there are too many configurations to keep straight that could change how
> > git interprets what should be a simple relative path to a file.
> 
> Thanks for digging.  Perhaps this needs to be documented (not "in
> this case it is take as relative to that, in this other case, ...",
> but "you cannot rely on relative being relative to something you
> think").

Documenting it that way feels like ¯\_(ツ)_/¯
I feel it should be made consistently relative to top of work tree.

Seems fairly unlikely that any scripts driving git rely on it
being relative to the pwd when GIT_WORK_TREE etc is set.

(I'd prefer relative to pwd because that is much more sane IMHO, but
making that change is more likely to break something.)

-- 
see shy jo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: GIT_INDEX_FILE relative path breaks in subdir

[Junio C Hamano]

Joey Hess <id@joeyh.name> writes:

> I feel it should be made consistently relative to top of work tree.
>
> Seems fairly unlikely that any scripts driving git rely on it
> being relative to the pwd when GIT_WORK_TREE etc is set.

Oh, I do agree that the current status may be a sign that nobody
that is cautious to cater to all possible cases would be relying on
the current behaviour in their scripts.  It is likely that their
scripts would first notice GIT_INDEX_FILE being relative, turn it
into absolute (or even error out---if the authors were aware of the
issue), before doing anything else.

But people do write their scripts assuming that they will never use
GIT_WORK_TREE environment (i.e. they rely on their workflow to stay
within a subset of cases you described in your message); IOW, it is
OK for them that their script is usable only in their workflow.

And once you start worrying about not breaking them, your update
would become a lot trickier.

I personally think that it would be OK as long as we do not change
behaviours for those who do not use core.worktree, $GIT_DIR and/or
$GIT_WORK_TREE and change behaviour for others to match that
behaviour, simply because the plain vanilla no-configuration would
be used by the largest number of people.  But depending on the size
of the "minority", you may get pushback from them.

> (I'd prefer relative to pwd because that is much more sane IMHO, but
> making that change is more likely to break something.)

I am not sure if relative to PWD is useful.  If it were relative to
either the GIT_DIR or the GIT_WORK_TREE, i.e. a fixed point, then
you can set and export GIT_INDEX_FILE and chdir around without
having to adjust it.  If it were relative to PWD, you would need to
adjust it every time you chdir, no?

Re: GIT_INDEX_FILE relative path breaks in subdir

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

Junio C Hamano wrote:
> I personally think that it would be OK as long as we do not change
> behaviours for those who do not use core.worktree, $GIT_DIR and/or
> $GIT_WORK_TREE and change behaviour for others to match that
> behaviour, simply because the plain vanilla no-configuration would
> be used by the largest number of people.  But depending on the size
> of the "minority", you may get pushback from them.

The minority affected would I think be limited to:

1. People who have a configuration that *always* sets core.worktree etc,
   and used GIT_INDEX_FILE with a cwd-relative path and it just happened
   to work for them.

2. People who have gone through the learning curve I've suffered about
   how relative GIT_INDEX_FILE works, and put in a workaround that's
   not the obvious "use an absolute path" workaround, but is more
   complex. Like, checking the git configs and adjusting what the
   variable is set relative to. And apparently nobody in this set felt
   worth mentioning this to the list..

I am unsure about the size of 1, and am sure 2 is small to nonexistant.

> I am not sure if relative to PWD is useful.  If it were relative to
> either the GIT_DIR or the GIT_WORK_TREE, i.e. a fixed point, then
> you can set and export GIT_INDEX_FILE and chdir around without
> having to adjust it.  If it were relative to PWD, you would need to
> adjust it every time you chdir, no?

Good point, I had not considered this use case. Although if I set a
long-term environment variable and expect to chdir around, well, that's
what absolute paths are for. All my uses of GIT_INDEX_FILE
are in short-term contexts where the program does not chdir.

-- 
see shy jo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: GIT_INDEX_FILE relative path breaks in subdir

[Junio C Hamano]

Joey Hess <id@joeyh.name> writes:

>> I am not sure if relative to PWD is useful.  If it were relative to
>> either the GIT_DIR or the GIT_WORK_TREE, i.e. a fixed point, then
>> you can set and export GIT_INDEX_FILE and chdir around without
>> having to adjust it.  If it were relative to PWD, you would need to
>> adjust it every time you chdir, no?
>
> Good point, I had not considered this use case. Although if I set a
> long-term environment variable and expect to chdir around, well, that's
> what absolute paths are for. All my uses of GIT_INDEX_FILE
> are in short-term contexts where the program does not chdir.

Same to you.  I didn't consider a single-shot

	$ GIT_INDEX_FILE=./a-temporary-file-here git do something

It would be natural if we have that temporary file here where we
are in that use case.