Bug in gitk search box

Bug in gitk search box

[Brian Downing]

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

Re: Bug in gitk search box

[Paul Mackerras]

Brian Downing writes:

> * 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

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.

Re: Bug in gitk search box

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> 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?

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

Re: Bug in gitk search box

[Paul Mackerras]

Junio C Hamano 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.

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.

Re: Bug in gitk search box

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> Junio C Hamano 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.
>
> 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.

I think that is indeed necessary.  How about this?

---
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 8216576..228ccaf 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -43,7 +43,9 @@
 	Synonym for "-p --stat".
 
 -z::
-	\0 line termination on output
+	NUL-line termination on output.  This affects the --raw
+	output field terminator.  Also output from commands such
+	as "git-log" will be delimited with NUL between commits.
 
 --name-only::
 	Show only names of changed files.

Re: Bug in gitk search box

[Marco Costalba]

On 7/26/07, Paul Mackerras <paulus@samba.org> wrote:
>
> OK, I'll have to change gitk then.  It looks like both Marco and I got
> tricked by this.

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