Browse Source

Fix a bug where we would corrupt the stuff read from git-rev-list.

If we have a very long commit message, and we end up getting a
bufferfull of data from git-rev-list that all belongs to one commit,
we ended up throwing away the data from a previous read that should
have been included.  The result was a error message about not being
able to parse the output of git-rev-list.

Also, if the git-rev-list output that we can't parse is long, only put
the first 80 chars in the error message.  Otherwise we end up with an
enormous error window.
maint
Paul Mackerras 20 years ago
parent
commit
7e952e797c
  1. 9
      gitk

9
gitk

@ -81,16 +81,21 @@ to allow selection of commits to be displayed.)} @@ -81,16 +81,21 @@ to allow selection of commits to be displayed.)}
while 1 {
set i [string first "\0" $stuff $start]
if {$i < 0} {
set leftover [string range $stuff $start end]
append leftover [string range $stuff $start end]
return
}
set cmit [string range $stuff $start [expr {$i - 1}]]
if {$start == 0} {
set cmit "$leftover$cmit"
set leftover {}
}
set start [expr {$i + 1}]
if {![regexp {^([0-9a-f]{40})\n} $cmit match id]} {
error_popup "Can't parse git-rev-list output: {$cmit}"
set shortcmit $cmit
if {[string length $shortcmit] > 80} {
set shortcmit "[string range $shortcmit 0 80]..."
}
error_popup "Can't parse git-rev-list output: {$shortcmit}"
exit 1
}
set cmit [string range $cmit 41 end]

Loading…
Cancel
Save