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

[Nguyen Thai Ngoc Duy <pclouds@gmail.com>]

On 12/29/09, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
>
>  > 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?

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