Re: GIT_INDEX_FILE relative path breaks in subdir

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

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?