# [BUG] gitk error - can't read "arcnos()": no such element in array 5 messages from 2021-05-03 to 2021-06-01. Participants: Chris Packham, Bagas Sanjaya. Thread: https://gitlist.dev/t/55614 ## Chris Packham, 2021-05-03 21:16 Subject: [BUG] gitk error - can't read "arcnos()": no such element in array Message-ID: URL: https://gitlist.dev/e/CAFOYHZBAg7pkise8bir7Z3qApw9mJB8Z99p6z71-_T6%3D7rFV7w%40mail.gmail.com ``` Hi, I'm hitting an error with gitk (gitk 1:2.31.1-0ppa1~ubuntu18.04.1) on a specific git repository. The repository is slightly odd in that it has some replace refs configured and multiple root commits. Although another similarly configured repo doesn't hit the error. The text from the application error pop-up is: can't read "arcnos()": no such element in array can't read "arcnos()": no such element in array while executing "lsearch -exact $arcnos($l) $a" (procedure "splitarc" line 21) invoked from within "splitarc $olds" (procedure "getallclines" line 33) invoked from within "getallclines file11" ("eval" body line 1) invoked from within "eval $script" (procedure "dorunq" line 11) invoked from within "dorunq" ("after" script) I've not been able to narrow down a specific reproduction method yet. Thanks, Chris ``` ## Chris Packham, 2021-05-31 03:11 Subject: Re: [BUG] gitk error - can't read "arcnos()": no such element in array Message-ID: URL: https://gitlist.dev/e/CAFOYHZAfQivHvs5%3DhGt-A1CbtwW-iJSwC1iFk7FY3wnNcVNVrQ%40mail.gmail.com In-Reply-To: ``` On Tue, May 4, 2021 at 9:16 AM Chris Packham wrote: > > Hi, > > I'm hitting an error with gitk (gitk 1:2.31.1-0ppa1~ubuntu18.04.1) on > a specific git repository. > > The repository is slightly odd in that it has some replace refs > configured and multiple root commits. Although another similarly > configured repo doesn't hit the error. > > The text from the application error pop-up is: > > can't read "arcnos()": no such element in array > can't read "arcnos()": no such element in array > while executing > "lsearch -exact $arcnos($l) $a" > (procedure "splitarc" line 21) > invoked from within > "splitarc $olds" > (procedure "getallclines" line 33) > invoked from within > "getallclines file11" > ("eval" body line 1) > invoked from within > "eval $script" > (procedure "dorunq" line 11) > invoked from within > "dorunq" > ("after" script) > > I've not been able to narrow down a specific reproduction method yet. This seems to have fallen on the floor (so I pick memorial weekend in the US to give it a ping). I have tried building gitk from source (git://ozlabs.org/~paulus/gitk) and still see the same problem. Still haven't reproduced it on anything other than my one repository. ``` ## Bagas Sanjaya, 2021-05-31 03:24 Subject: Re: [BUG] gitk error - can't read "arcnos()": no such element in array Message-ID: URL: https://gitlist.dev/e/aa18c448-9a74-0837-a2bb-008aab31f0e4%40gmail.com In-Reply-To: ``` On 31/05/21 10.11, Chris Packham wrote: > This seems to have fallen on the floor (so I pick memorial weekend in > the US to give it a ping). > > I have tried building gitk from source (git://ozlabs.org/~paulus/gitk) > and still see the same problem. Still haven't reproduced it on > anything other than my one repository. > So this issue is repo-specific, right? Is your problematic repo public? If so, we can test against that. -- An old man doll... just what I always wanted! - Clara ``` ## Bagas Sanjaya, 2021-05-31 07:53 Subject: Re: [BUG] gitk error - can't read "arcnos()": no such element in array Message-ID: URL: https://gitlist.dev/e/d919f68e-42a9-bd74-c16e-8d2c185b6938%40gmail.com In-Reply-To: ``` On 31/05/21 14.38, Chris Packham wrote: >> Is your problematic repo public? If so, we can test against that. >> > > Unfortunately not. It's actually an internal kernel tree which has a > different root to upstream (hence using git replace to attach upstream). > All of which make the history a bit funky. > > I don't know if the problem will survive anonymisation but I can try. > Did you mean vendor kernel tree based on Linux kernel? I think you can try reproducing the issue with either Linus' tree [1] (mainline only) or Greg's stable tree [2] (mainline + release branches and tags). [1]: https://github.com/torvalds/linux [2]: https://github.com/gregkh/linux -- An old man doll... just what I always wanted! - Clara ``` ## Chris Packham, 2021-06-01 00:29 Subject: Re: [BUG] gitk error - can't read "arcnos()": no such element in array Message-ID: URL: https://gitlist.dev/e/CAFOYHZAjzS%2BfizM%2BwadgFq3F6tSYu35CJOFuCWPFc5TH6Fq8vg%40mail.gmail.com In-Reply-To: ``` On Mon, May 31, 2021 at 7:53 PM Bagas Sanjaya wrote: > > On 31/05/21 14.38, Chris Packham wrote: > >> Is your problematic repo public? If so, we can test against that. > >> > > > > Unfortunately not. It's actually an internal kernel tree which has a > > different root to upstream (hence using git replace to attach upstream). > > All of which make the history a bit funky. > > > > I don't know if the problem will survive anonymisation but I can try. > > > > Did you mean vendor kernel tree based on Linux kernel? Kind of. A repo that was created in 2007 before we were using git properly by extracting the kernel tarballs and adding our code. So although it's a kernel tree it shares no common history with Linus' tree. git fast-export/fast-import doesn't seem to like the affected repo so I'm not having much luck with making anything publicly available. > I think you can > try reproducing the issue with either Linus' tree [1] (mainline only) or > Greg's stable tree [2] (mainline + release branches and tags). > > [1]: https://github.com/torvalds/linux > [2]: https://github.com/gregkh/linux > I've tried a few experiments - cloning the "bad" repo -> no problem seen in clone - cloning the "bad" repo with --mirror -> no problem seen in clone - copying the "bad" repo -> same problem seen in copy So now that I have a copy that shows the problem I can do a few more things. - copy repo, remove replace refs (git replace -l | xargs git replace -d) -> problem remains - copy repo, remove replace refs and all remotes except origin -> problem remains - copy repo, run git gc -> no problem So the git gc seems to have done the trick. I'm happy enough to leave it there and hope that this thread is useful for future mailing list searchers. I'll keep a copy of the affected repo around if there is anything someone wants me to try. ```