threads / discuss / 665

git-diff-tree for the first commit

Subject: git-diff-tree for the first commit

## tl;dr

4 messages between May 19, 2005 and May 19, 2005.

replies: 3people: 2as markdown or json

Thomas Glanzmann· May 19, 2005, 19:51 UTC · lore

Hello, 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?
	Thomas
Linus Torvalds· May 19, 2005, 20:31 UTC · re: Thomas Glanzmann · lore

Re: git-diff-tree for the first commit

On Thu, 19 May 2005, Thomas Glanzmann wrote:
Show 6 quoted lines
>
> 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
Thomas Glanzmann· May 19, 2005, 20:38 UTC · re: Linus Torvalds · lore

Re: git-diff-tree for the first commit

Hello, I see. Thanks for the elaboration. I got the idea now. ;-)

> 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.
I want it for the following scenario:

My git frontend sets the time stamps of the checked-out files to the time of the last modification. That way I can do a 'ls -lart' in a sub directory and have the most recently touched files on bottom. I also want to use this for keyword expansion.

I currently do it by calling more or less 'git-rev-tool HEAD' and 'git-diff-tree -r REVISION' and cache the output. However for the inital import are no 'timestamps' available. Now I can do two things. Implement a git-diff-tree flag or assume that any files which don't have a delta are imported by the initial tree.

Ideas?
	Thomas
Linus Torvalds· May 19, 2005, 20:46 UTC · re: Linus Torvalds · lore

Re: git-diff-tree for the first commit

On Thu, 19 May 2005, Linus Torvalds wrote:
> 
> 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.

Done. Use "git-diff-tree --root" if you want to see the root commit as a big diff against nothing.

		Linus

← back to recent threads