diff options
author | Paul Mackerras <paulus@samba.org> | 2009-03-02 09:38:17 +1100 |
---|---|---|
committer | Paul Mackerras <paulus@samba.org> | 2009-03-02 09:38:17 +1100 |
commit | 52b8ea934ecd24b52806188b53367aaa6185deb3 (patch) | |
tree | 436e0c06b3e15172cafd39067473192d8dd5eacd /gitk-git | |
parent | e4df519f05ab20eae235968166a17a5a196bc377 (diff) | |
download | git-52b8ea934ecd24b52806188b53367aaa6185deb3.tar.gz git-52b8ea934ecd24b52806188b53367aaa6185deb3.tar.xz |
gitk: Fix possible infinite loop and display corruption
This fixes an issue reported by Johannes Sixt on the git mailing list:
> This recipe sends gitk into an endless loop. In git.git do:
>
> cd t
> # remove chmod a+x A near the end of the file
> sed -i 's/chmod/: chmod/' t3400-rebase.sh
> sh t3400-rebase.sh --debug
> cd trash\ directory.t3400-rebase/
> gitk master modechange modechange@{1}
>
>
> I briefly see the history chart, but the dot that should be modechange@{1}
> is missing. One automatically selected commit is shown in the diff section
> below. But then the commit list is cleared and gitk goes into an infinite
> loop.
>
> Things work alright if either modechange@{1} is dropped, or the 'chmod'
> line is left unchanged, which is a bit strange.
>
> This is with git version 1.6.1.2.390.gba743
There were actually two problems. This recipe created a situation where
git log would output a child commit after its parent. This meant that
we called fix_reversal which called splitvarc, which should call modify_arc
to note the fact that it has modified the arc that it has just split. It
wasn't, which meant that displayorder and other variables got into an
inconsistent state (a commit appearing twice in displayorder).
This then meant that the targetrow/targetid logic in drawvisible thought
it need to redraw each time. That, together with the fact that drawvisible
called drawcommits which called drawvisible if a redraw was needed, led
to the infinite loop.
In fact drawvisible is now the only caller of drawcommits. Thus, the
start and end row arguments to drawcommits always encompass the whole
visible area, so drawcommits doesn't need to call drawvisible to redraw;
it just needs to clear the screen and draw what it's been asked to.
This fixes these two problems by adding a call to modify_arc in
splitvarc and by taking out the call to drawvisible in drawcommits.
It also removes an unrelated left-over debugging puts in external_blame.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'gitk-git')
0 files changed, 0 insertions, 0 deletions