gitk - error in git repo on cygwin

gitk - error in git repo on cygwin

[Mark Levedahl]

Beginning with commit "[66e46f37de3ed3211a8ae0e8fc09c063bc3a1e08] gitk: 
Store ids in rowrangelist and idrowranges rather than row numbers", gitk 
run on Cygwin encounters an error looking at the git repository. The 
error occurs during startup (just run gitk on master), with error:

can't read "commitrow(0,8572)": no such element in array
can't read "commitrow(0,8572)": no such element in array
    while executing
"lappend linenos $commitrow($curview,$rid)"
    (procedure "rowranges" line 14)
    invoked from within
"rowranges $id"
    (procedure "optimize_rows" line 21)
    invoked from within
"optimize_rows $rowoptim 0 [expr {$rowoptim + $nr}]"
    (procedure "layoutmore" line 16)
    invoked from within
"layoutmore $tlimit $allread"
    (procedure "chewcommits" line 9)
    invoked from within
"chewcommits 0"
    ("eval" body line 1)
    invoked from within
"eval $script"
    (procedure "dorunq" line 9)
    invoked from within
"dorunq"
    ("after" script)

This doesn't happen on my Linux box, so this is most likely due to a tcl 
feature introduced more recently than the tcl used in Cygwin (8.4.1). My 
guess would be that the more recent tcl is more forgiving of an 
attempted access to a non-existent element.

Mark

Re: gitk - error in git repo on cygwin

[Paul Mackerras]

Mark Levedahl writes:

> This doesn't happen on my Linux box, so this is most likely due to a tcl 
> feature introduced more recently than the tcl used in Cygwin (8.4.1). My 
> guess would be that the more recent tcl is more forgiving of an 
> attempted access to a non-existent element.

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.

Re: gitk - error in git repo on cygwin

[Mark Levedahl]

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