Paul Mackerras wrote:
I don't think anything like that has changed. I think it is probably
due to the commits being batched up differently in getcommitlines.
I'll look into it.
Paul.
Indeed, it does seem to be something order dependent. I added some debug
printouts, and looking in proc "rowranges" when the error occurs (for
gitk f77a29e), I get:
$commitrow($curview,$id) = 8571
[lindex $rowrangelist $commitrow($curview,$id)] =
29504118f8528f658fd0bfc02d8d78d4c01dc2cc 8571
In all previous cases, the lindex expression evalutates to two sha1's.
So clearly, the order of processing is different. I did check that the
input (from git-rev-list) is identical across the linux and Cygwin
invocations. Shrug.
Mark
-
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
