git-diff not showing changes (corrupt repo?)

Hi, A small personal git repository has started lying to me about changed files. git-diff sometimes tells me that the index has no changes from HEAD, while other commands (git-status, at least) seem to tell the truth. 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.

I have tried git versions 1.5.1.6-1.5.3.3, and they all act the same, so I think the repository is corrupt. Does sound familiar to anybody? If this is user error (for example, "git-reset --hard HEAD^" on a branch that had already been pulled into another branch), I can restore from a recent backup and redo some changes, but I would like to help troubleshoot this behavior if it is a git bug. Is this a known behavior? git-fsck doesn't reveal anything amiss, besides dangling objects. Does anybody know anything about this situation or what can cause it?

Example of behavior:

$ git status # On branch bak_linear-checks3 nothing to commit (working directory clean) $ echo "test" >> Makefile $ git status # On branch bak_linear-checks3 # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: Makefile # no changes added to commit (use "git add" and/or "git commit -a") $ git diff $

Thanks, Dan

Dan Zwell <dzwell@gmail.com> writes:

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.

Do you mean 1.5.1.5 was Ok?  Can you bisect it?

Not to me; and I do not think repository is corrupt from the two "HEAD^ vs HEAD" diff. There is something entirely different going on.

Thanks.

Junio C Hamano wrote:
 > Dan Zwell <dzwell@gmail.com> 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@admingilde.org>
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

On Tue, Oct 02, 2007 at 10:17:41PM -0500, Dan Zwell wrote:

The only thing this patch does is run the pager, so presumably git-diff _is_ generating output, but calling the pager is broken for some reason. What is the value of $GIT_PAGER and $PAGER on the broken and working machines? Can you confirm that the pager works on both machines?

I couldn't reproduce on my 32-bit or 64-bit machine (the former running Debian unstable, the latter Debian stable). But given the patch you bisected to, I think it is more likely that your pager is broken on the 64-bit machine.

-Peff

Jeff King wrote:
 > On Tue, Oct 02, 2007 at 10:17:41PM -0500, Dan Zwell wrote:
 >
 >> e88ee2915493213ea0d0be64c542c090fefd4b33 is first bad commit
 >> commit e88ee2915493213ea0d0be64c542c090fefd4b33
 >> Author: Martin Waitz <tali@admingilde.org>
 >> Date:   Tue Oct 10 21:16:25 2006 +0200
 >>
 >>     paginate git-diff by default
 >
 > The only thing this patch does is run the pager, so presumably git-diff
 > _is_ generating output, but calling the pager is broken for some reason.
 > What is the value of $GIT_PAGER and $PAGER on the broken and working
 > machines? Can you confirm that the pager works on both machines?
 >

You're absolutely right, my pager was being called and exiting. My system configuration must be dodgy, because "echo hi | less --quit-if-one-screen" does not display anything unless it in run in "screen". But that's not git's fault, and I just need different options, for now. Thanks a lot for helping me solve this.

Dan

 >
 > -Peff
 >

On Tue, Oct 02, 2007 at 11:00:16PM -0500, Dan Zwell wrote:

This is obviously getting into less debugging (about which I know little), but it's possible that you have a bogus TERM setting.

Thank you for providing such helpful details. It really makes a difference.

-Peff

On Tue, 2 Oct 2007, Dan Zwell wrote:

You most likely have a very buggy "less".

Try this:

	echo hello | less -FRSX

on the command line. Do you see the "hello"?

(The above is assuming you haven't set GIT_PAGER, PAGER or the LESS variables manually to something else)

		Linus

On Tue, Oct 02, 2007 at 01:55:16PM -0500, Dan Zwell wrote:

Perhaps you are confused by the fact that "git-diff" with no options shows the difference between the index and the working tree? Did you try "git-diff --cached"?

That doesn't seem right. Can you reproduce this, or at least show us the command you used?

OK, that does seem wrong. If you run git-diff-files, does it produce the expected output?

-Peff