Joey Hess <id@xxxxxxxxxx> 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? -- 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