Re: git-diff-tree for the first commit

On Thu, 19 May 2005, Thomas Glanzmann wrote:

I would like to see output for the first commit (initial import) in:

	git-rev-list HEAD | git-diff-tree -r --stdin

is it supposed to just be empty or is that a bug?

Hmm.. That's a bug and/or a feature, entirely depending on how you feel.

The first commit doesn't have a parent, so in the world where this is a 
feature, this is 100% consistent with the notion that since there is 
nothing to diff against, diff-tree has nothing to do.

In an alternate world, you can decide that not having a parent is 
equivalent to being parented with an empty tree.

In yet a third world, you'd decide that all git projects should start off 
from the empty tree root parent, and that the kernel project (and the git 
archive itself) is invalid.

I don't think there is a right answer, except that I think the third
version is likely wrong, since by definition the kernel archive is
perfect.

There's actually some reason to consider the current behaviour correct, in
that the initial tree really _is_ special: it was imported from somewhere
else, and as such anybody who wants to know "what changed" really doesn't
want to see the explosion that happened at the beginning of time: that
wasn't a "change" at all, that was something else.

So the current behaviour actually is (in my opinion) the right one, at
least when considering something like git-whatchanged. Similarly, if you
use a variation of git-whatchanged to implement the equivalent of "cvs
annotate", leaving the lines that don't have a diff _non-annotated_ is
actually the right thing to do, since it would be wrong to say "they came
from the person who did the initial import".

That said, a new flag that says "diff the root against the NUL tree" 
wouldn't be wrong either, for when that is what you want.

			Linus