Paul,
The previous bug I reported of gitk giving an error on Cygwin, and that
you addressed in 8c93917d23ec7ef998154a, now manifests itself
differently in that all commits are not shown. For instance, "gitk
v1.5.3-rc1" results in a display where the last shown commit is 9e026d3
(dated 205-09-26), the tag v0.99.8g is the penultimate shown, both are
shown with white circles at the tip of their respective commit lines.
12-15 previous commits are shown in the same way. The correct display of
course begins with commit e83c51 on 2005-040-7.
I have built a new tcl/tk package, using 8.4.15 sources, using POSIX +
X-Windows under Cygwin, and using this tcl/tk package I get identical
(assumed correct) results as I do on my fedora FC7 box. (Such a package
cannot be introduced into Cygwin as the Tcl/Tk package there is the one
that supports the insight debugger, and the Tcl/Tk sources are
integrated into the insight debugger source tree).
Further investigation has shown that:
1) The contents read in getcommitlines is identical (I logged from both
versions and compared the results).
2) The Posix-X windows version (and on Linux) in general reads 50,000
bytes at a time from the pipe, as would be expected from the line "
set stuff [read $fd 500000]"
3) The normal Cygwin TCL version reads 3000 - 5000 bytes at a time, not
50,000.
4) gitk, prior to commit 8c93917, would throw an error when trying to
layout the row that now shows up as the last commit.
So, my suspicion is that the layout code gets ahead of the read loop,
requiring data for a commit not yet read in, and prematurely terminates
the graph rather than waiting for more data to be read in before
attempting to continue the layout. Just a guess as I do not really
understand the pseudo-threading you have written.
Mark Levedahl
-
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
