gitk dev branch: F5 problem again

gitk dev branch: F5 problem again

[Johannes Sixt]

I'm using gitk's dev branch (476ca63d Index [fnvr]highlights by id...) on
Windows.

Start gitk like this:

   gitk somefile.c

while on a branch whose tip touches somefile.c.

Now:

   git commit --amend

Then press F5 in gitk. I get these error reports after which gitk is
unresponsive:

can't read "children(1,)": no such element in array
can't read "children(1,)": no such element in array
    while executing
"lindex $children($curview,$id) 0"
    (procedure "ordertoken" line 15)
    invoked from within
"ordertoken $id"
    (procedure "idcol" line 2)
    invoked from within
"idcol $idlist $id"
    (procedure "layoutrows" line 51)
    invoked from within
"layoutrows $rl1 $r"
    (procedure "drawcommits" line 36)
    invoked from within
"drawcommits $row $endrow"
    (procedure "drawvisible" line 51)
    invoked from within
"drawvisible"
    (procedure "scrollcanv" line 3)
    invoked from within
"scrollcanv .tf.histframe.csb 0.00852273 0.146591"


... same as above ...
"drawvisible"
    (procedure "scrollcanv" line 3)
    invoked from within
"scrollcanv .tf.histframe.csb 0.0170455 0.155114"


... same as above ...
"drawvisible"
    ("eval" body line 1)
    invoked from within
"eval $script"
    (procedure "dorunq" line 9)
    invoked from within
"dorunq"
    ("after" script)


-- Hannes

Re: gitk dev branch: F5 problem again

[Paul Mackerras]

Johannes Sixt writes:

> I'm using gitk's dev branch (476ca63d Index [fnvr]highlights by id...) on
> Windows.
> 
> Start gitk like this:
> 
>    gitk somefile.c
> 
> while on a branch whose tip touches somefile.c.
> 
> Now:
> 
>    git commit --amend
> 
> Then press F5 in gitk. I get these error reports after which gitk is
> unresponsive:
> 
> can't read "children(1,)": no such element in array

Thanks.

I found the reason for the Tcl errors - an incorrect optimization in
make_disporder - and I have pushed out a fix.

However, that shows up another problem, due to the way parent
rewriting does (or doesn't) work when we are limiting both by
revisions and by path.  When you press F5 in the above scenario, you
will get the new version of the commit, with its real parent shown as
an open-circle commit, disconnected from the rest of the graph.

What's happening here is that to do the update, gitk first re-reads
all the references, notices that the head has changed, and does a git
log command like:

	git log newhead ^oldhead -- somefile.c

The git log traversal stops as soon as it finds a commit which is an
ancestor of oldhead, which in this case will be oldhead's (and
newhead's) real parent.  Because the traversal doesn't go far enough
to find another commit that touches somefile.c (which would be the
fake parent that gitk would want to use for the graph), the parent
rewriting doesn't happen and git log outputs the newhead commit with
its real parent rather than a fake parent.  Assuming the real parent
doesn't touch somefile.c, it is a commit that gitk doesn't have in its
graph, so it can't join newhead into the existing graph properly.  I'm
not sure how best to fix that.  I'll have to think about it.

Paul.