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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
