oh, wow, this got over my head *real* fast. Okay, 1. Yeah, my `$GIT_WORK_TREE` was def. an absolute path; I typed that example code without running it *precisely* that way (entirely my mistake! I'm so sorry for the confusion it caused, and all that typing you did!); if I remember correctly (not at the machine right now), I had run `git rev-parse --show-toplevel` from a different directory, with `$GIT_DIR` set, while trying to narrow down this bug, so it gave me an absolute path … and then copy-pasted that path, and then replaced my copy-paste with the original command to make the bug-report example as concise as possible? oops. But, yeah, it fails in the manner described above with an absolute path. (Which it looks like you two figured out above.) 2. Re: intentions, again, it seems like you've changed your mind, but … > So it is a misconfiguration if you only set GIT_WORK_TREE without setting GIT_DIR. I really, really hope not! Half the usefulness of `$GIT_WORK_TREE` existing is in that mode. In fact, that's how I found `$GIT_WORK_TREE` documented and explained, in [this blog post](https://git-scm.com/blog/2010/04/11/environment.html) on the Git site. That usage seems pretty damn useful, so I do hope it's eventually explicitly supported … (and if that's *not* going to be the case, it should be explicitly documented in the `GIT(1)` manpage, alongside the other documentation of the environment-variables, that the behaviour is undefined is `$GIT_DIR` isn't set first. =) ⁓ ELLIOTTCABLE — fly safe. http://ell.io/tt -- 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