gitk dev branch: F5 problem again

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

Johannes Sixt writes:

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.