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
threads / discuss / 665
Subject: git-diff-tree for the first commit
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
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
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
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