Re: git diff vs git diff-files

On Tue, Aug 14, 2012 at 10:18 AM, Thomas Rast [off-list ref] wrote:

That sounds like an issue with stat() data, and then it doesn't.  cp -a
would change all the inode numbers, triggering a full refresh of the
index in 'git diff'.  But I'm not sure exactly how this can lead to
disagreement, since both commands read *both* index and worktree version
of the file.  Very confusing.

Can you try the following:

  git ls-files --debug gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
  cp .git/index .git/index.orig
  touch gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
  # note, it is important that you run diff first
  git diff gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
  git diff-files -p gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
  git ls-files --debug gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net

I'm can't tell what this was supposed to prove, but I think it's
proven that I'm in the wrong mailing list, and that I should be taking
this up with gnome-terminal. The Q1 part deletion line seems to be
appearing (in the terminal) only after I've copy&pasted it into
another terminal.

Running the same commands in xterm (correctly) shows the Q1 part
deletion line without having to copy & paste.

At this point I doubt there's much value in publishing the output, but
just in case (and it may be relevant when i take it to
gnome-terminal), it's here:

http://www.bpj-code.co.za/downloads.php/bugs/git-output-87vcgl999v.fsf?text

Note that line 104 of that output appears in the same terminal from
which I copy&paste it only after I switch back to it, after having
pasted the output. Oi vey.

quoted

http://www.bpj-code.co.za/downloads.php/bugs/TwoStageAmp-output.net?text
contains the output from git show a5ee1e7. Leave off the ?text for an
application/octet-stream download.

Umm, that's only one side of the diff, isn't it?  The hunk header claims
that the hunk goes up to line 47, so there must be more changes beyond
what you showed.

You're right - the hunk isn't even self-consistent!
http://www.bpj-code.co.za/downloads.php/bugs/git-add--p-TwoStageAmp-output.net?text
is the "bad" diff, and I count only 46 lines of (context + deletions),
while the hunk header claims the (correct) 47 lines corresponding to
the whole file covered in the hunk.

Thanks for your time; I'm fairly convinced now that git is just an
innocent accessory to another program's bug.