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