Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE

From: Nanako Shiraishi <nanako3@lavabit.com>
Date: Dec 29, 2009, 11:04 UTC
Message-ID: <20091229200426.6117@nanako3.lavabit.com>
In-Reply-To: <fcaeb9bf0912290038u77a5e83cqe2f3cbfab05af263@mail.gmail.com>

Quoting Nguyen Thai Ngoc Duy <pclouds@gmail.com>:

Show 16 quoted lines

> On 12/29/09, Fyn Fynn <fynfynn@gmail.com> wrote:
>> The exact same git reset command that works in 1.6.4, fails to work
>>  under 1.6.6:
>>
>>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>>  /usr/local/git-1.6.6/bin/git reset --hard
>>  fatal: hard reset requires a work tree
>>  $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>>  /usr/local/git-1.6.4/bin/git reset --hard
>>  HEAD is now at 77ec73f...
>>
>>  What gives?
>
> A recent patch by Jeff (952dfc6 (reset: improve worktree safety valves
> - 2009-12-04)) makes sure that "git reset --hard" will not work
> outside worktree (which is right).

Sorry, but I don't understand why it is *right*. Isn't 'git reset --hard' supposed to make all the files in the working tree match the HEAD, no matter where you start from?

Jeff's commit message says:

        make sure we are in a worktree. Otherwise, we can end up
	munging files inside of '.git'

But if you have ~/myproject/.git project, whose working tree is ~/myproject, and if you run

        % cd ~/myproject/.git
	% git reset --hard

the code mistakenly overwrote files in ~/myproject/.git directory before Jeff's patch, and I agree it was a bug.

But shouldn't the correct fix be to go to ~/myproject, the obvious root level of the working tree, and check out the files in that directory?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/