From: Nanako Shiraishi Date: Tue, 29 Dec 2009 11:04:26 GMT Subject: Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE Message-ID: <20091229200426.6117@nanako3.lavabit.com> In-Reply-To: Quoting Nguyen Thai Ngoc Duy : > On 12/29/09, Fyn Fynn 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/