Bug in gitk search box

To reproduce:

* Open gitk in any repository, the Git one seems to work fine.
* Type a string that it won't find into the search box, like 'asdfasdf'.
* Click find.

You'll get:

can't read "commitdata(e83c5163316f89bfbde7d9ab23ca2e25604af290)": no such element in array
can't read "commitdata(e83c5163316f89bfbde7d9ab23ca2e25604af290)": no such element in array
    while executing
"doesmatch $commitdata($id)"
    (procedure "findmore" line 21)
    invoked from within
"findmore"
    ("eval" body line 1)
    invoked from within
"eval $script"
    (procedure "dorunq" line 9)
    invoked from within
"dorunq"
    ("after" script)

Where the SHA1 is always the earliest SHA1 in the rev-list gitk is examining.

After this happens you get a "busy cursor" when hovering over most of gitk, and you can't search again until gitk is restarted.

-bcd

Brian Downing writes:

It turns out that this problem crept in when I changed from using git rev-list --header to git log -z --pretty=raw, and the thing that causes it is that git rev-list puts a null character after every commit, while git log only puts a null between commits, i.e., there isn't a null after the last commit.

Junio, is this behaviour deliberate?

Paul.

Paul Mackerras <paulus@samba.org> writes:

There was a recent message from Linus on the list, stating that NUL in -z format is inter-record separator, not after-record terminator.

Junio C Hamano writes:

OK, I'll have to change gitk then. It looks like both Marco and I got tricked by this. I suggest it's worth a mention in the documentation.

Paul.

Paul Mackerras <paulus@samba.org> writes:

I think that is indeed necessary.  How about this?

---

On 7/26/07, Paul Mackerras <paulus@samba.org> wrote:

Yes. With commit c1672ba272c8e of 22 of Jun I make qgit to always append a '\0' at the end of the stream so to avoid to change parsing function.

Marco