Quoting Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx>:
> On 12/29/09, Fyn Fynn <fynfynn@xxxxxxxxx> 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/
--
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