On Wed, Nov 25, 2015 at 9:13 PM, Duy Nguyen <pclo...@gmail.com> wrote:
> On Tue, Nov 24, 2015 at 6:57 PM, Stefan Beller <sbel...@google.com> wrote:
>> +to Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
>>
>> On Mon, Nov 23, 2015 at 6:22 PM, Anthony Sottile <asott...@umich.edu> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to