On Wed, Nov 25, 2015 at 9:13 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Tue, Nov 24, 2015 at 6:57 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >> +to Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> >> >> On Mon, Nov 23, 2015 at 6:22 PM, Anthony Sottile <asottile@xxxxxxxxx> wrote: >>> * Short description of the problem * >>> >>> It seems GIT_WORK_DIR is now exported invariantly when calling git >>> hooks such as pre-commit. If these hooks involve cloning repositories >>> they will not fail due to this exported environment variable. This >>> was not the case in prior versions (such as v2.5.0). > > I'm getting good at fixing one bug and adding ten more. I don't think > the cited commit is the problem. It just exposes another bug. I did > >> ~/w/git $ GIT_WORK_TREE=abc ./git clone .git /tmp/def > > and what I got was really surprising, /tmp/def contains the git > repository while the true worktree is in "abc". It does not make > sense, at least from the first sight, unless it inherits this from > git-init, where we do(?) want GIT_WORK_TREE to specify a separate > worktree. No time to dig to the bottom yet.. I was wrong, GIT_WORK_TREE support was added in git-clone many years ago in 20ccef4 (make git-clone GIT_WORK_TREE aware - 2007-07-06). So my change accidentally triggers an (undocumented) feature. We could add a hack to ignore GIT_WORK_TREE if GIT_DIR is set too, but I don't think people will like it. I don't really like reverting d95138e (setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR - 2015-06-26) because another bug reappears. So I'm out of options.. -- Duy -- 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