Junio C Hamano wrote:
> Dan Zwell <dzwell@xxxxxxxxx> writes:
>
>> ... It is the same after I commit the new changes--at that point,
>> "git-diff-tree HEAD^ HEAD -p" spits out a nice patch, but "git-diff
>> HEAD^ HEAD" gives nothing.
>
> This part is most interesting. They are both about comparing
> two commits and do not interact with anything in the work tree
> nor your index.
>
> ... Can you bisect it?
>
I bisected twice to be sure, and have CC'd Martin Waitz on this (the
issue is that some of my changes in a local repo are not being displayed
by git-diff, either before or after they are committed, but git-status,
git-whatchanged, and git-diff-tree all see that changes have been
committed, and git-diff-files does see uncommitted changes).
e88ee2915493213ea0d0be64c542c090fefd4b33 is first bad commit
commit e88ee2915493213ea0d0be64c542c090fefd4b33
Author: Martin Waitz <tali@xxxxxxxxxxxxxx>
Date: Tue Oct 10 21:16:25 2006 +0200
paginate git-diff by default
I discovered this problem on my 64 bit machine, but the problem does not
occur on my 32 bit machine. That is not the only difference between the
two computers, but it seems the most obvious culprit. The 64 bit machine
may have different libraries than the other, as they are running
different distros.
I noticed that this is a rather old (and very small) patch, and I don't
quite understand how it could cause this problem. I could not revert the
patch to fix the problem. I placed a stripped down version of the
repository here: http://zwell.net/git-error.tar.gz. The problem is very
easy to observe on my machine, though it looks like some machines do not
exhibit it. What else can I do to help?
Dan
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
