Bernd Jendrissek [off-list ref] writes:
On Mon, Aug 13, 2012 at 5:02 PM, Thomas Rast [off-list ref] wrote:
quoted
Can you share this repository?
This weird behaviour doesn't even survive making a copy (cp -a) of the
whole repository, so I very much doubt making it available would be
illuminative. My disk's SMART data seems okay. The weird-quotient just
rose a bit.
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
quoted
Or at least the pre- and post-change
files, transferred in such a way that there won't be any whitespace
damage (your snippets above show obvious damage). You can use
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.
--
Thomas Rast
trast@{inf,student}.ethz.ch
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.