From: Nguyen Thai Ngoc Duy Date: Tue, 29 Dec 2009 11:36:09 GMT Subject: Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE Message-ID: In-Reply-To: <20091229200426.6117@nanako3.lavabit.com> On 12/29/09, Nanako Shiraishi wrote: > 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? It is generally "right" to work from inside worktree, the way Git worked before GIT_WORK_TREE came. In case of "git reset --hard", yes it'd be best if Git could just go to worktree and reset it. I forgot that "git reset --hard" does not take pathspec. The situation may be a bit more complicated with "git status" (which also handles worktree as a whole) because you may need to represent the filename output to be relative to current working directory, not the GIT_WORK_TREE. Using GIT_WORK_TREE from outside worktree is imo stretching git to its limits. -- Duy