Re: behaviour of git diff, GIT_DIR & checked out tree

Johannes Schindelin [off-list ref] writes:

On Mon, 24 Sep 2007, David Tweed wrote:

quoted

... In
a different directory, OUTSIDE of $HOME/V, I tried

env GIT_DIR=$HOME/V/.git git diff master@{midnight}

to get the same effect but, whilst I do get a diff output, it
looks like a diff of the commit against an empty tree.

Yes, this is fully expected.

The @{time} notation accesses the _reflogs_, which are purely local 
beasts.  They are not transmitted when cloning.

Yeah, but my reading of the problem description suggests the two
cases refer to the same repository (hence the same reflogs).

The issue is that the second case runs "git diff <one-tree>" in
a random directory.  This form is about comparing the part of
work tree you are in with a given tree, and does not make _any_
sense when outside the work tree.  Usually without GIT_DIR
environment, the command would give you an error message.

With $GIT_DIR, but without $GIT_WORK_TREE, the user is telling
the command that it is being run at the top level of the work
tree and the repository metadata is not in the usual ".git"
subdirectory of the top level of the work tree (in this case, by
definition that is "$PWD/.git") but elsewhere where $GIT_DIR
specifies.  Because it is very likely that the files under the
random location does not share much resemblance to what are in
$HOME/V, it is not surprising that the output consisted of many
deletions.

It would be illustrative if David did the following.

	$ cd $HOME
        $ cp -a V W
        $ rm -fr W/.git
        $ cd W
        $ GIT_DIR=$HOME/V/.git git diff @{midnight}

Now we are in a random place outside of the work tree
(i.e. "W"), and we drive "git diff" with GIT_DIR specified,
telling it to pretend that we are at the top level of the work
tree.  So ~/W/frotz is compared with "frotz" at the top level of
the commit (which usually is compared with ~/V/frotz), etc.  But
the directory we happen to be in very much resembles the work
tree, so it would give identical results to

	$ cd $HOME/V
        $ git diff @{midnight}

On 9/24/07, Junio C Hamano [off-list ref] wrote:

It would be illustrative if David did the following.

        $ cd $HOME
        $ cp -a V W
        $ rm -fr W/.git
        $ cd W
        $ GIT_DIR=$HOME/V/.git git diff @{midnight}

Now we are in a random place outside of the work tree
(i.e. "W"), and we drive "git diff" with GIT_DIR specified,
telling it to pretend that we are at the top level of the work
tree.  So ~/W/frotz is compared with "frotz" at the top level of
the commit (which usually is compared with ~/V/frotz), etc.  But
the directory we happen to be in very much resembles the work
tree, so it would give identical results to

        $ cd $HOME/V
        $ git diff @{midnight}

To separate the two issues, I did all the commands to the diff
above and then removed one directory from the tree in W.

GIT_DIR=$HOME/V/.git git diff master~1
(which ought not need reflogs, right) and it gave a diff between
the contents of W and master~1. I also tried with commit
master@{midnight} and that also gave the difference between
W and the last commit yesterday. So Junio's explanation of what's going on
is right. I'm just asking if there's a way to say
"the `working dir' associated with this git dir" explicitly (in the same
way I can use `HEAD' to refer to the topmost commit on the
current branch) when you're not somewhere within the 'working dir'.
If there's not I can alias around it with
"cd $HOME/V && command && cd -". (As I say, for reasons unrelated
to git usage I don't actually "do work" within the tracked tree.)

Many thanks,

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee