gitk: Parse arbitrary commit-ish in SHA1 field
We only accepted either SHA1s or heads/tags that have been read. This meant the user could not, e.g., enter HEAD to go back to the current commit. This adds code to call out to git rev-parse --verify if all other methods of interpreting the string the user entered fail. (git-rev-parse alone is not enough as we really want a single revision.) The error paths change slighly, because we now know from the rev-parse invocation whether the expression was valid at all. The previous "unknown" path is now only triggered if the revision does exist, but is not in the current view display. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
Thomas Rast committed
Aug 13, 2009 at 09:25 UTC
9bf3acfadafe9e5961296ff22a1677a9f5afe508
1 file changed
+6
-1
gitk
+6
-1
@@ -7909,6 +7909,11 @@ proc gotocommit {} {
7909
}
7910
set id [lindex $matches 0]
7911
}
7912
+ } else {
7913
+ if {[catch {set id [exec git rev-parse --verify $sha1string]}]} {
7914
+ error_popup [mc "Revision %s is not known" $sha1string]
7915
+ return
7916
+ }
7917
}
7918
}
7919
if {[commitinview $id $curview]} {
@@ -7918,7 +7923,7 @@ proc gotocommit {} {
7923
if {[regexp {^[0-9a-fA-F]{4,}$} $sha1string]} {
7924
set msg [mc "SHA1 id %s is not known" $sha1string]
7925
} else {
7921
- set msg [mc "Tag/Head %s is not known" $sha1string]
7926
+ set msg [mc "Revision %s is not in the current view" $sha1string]
7927
}
7928
error_popup $msg
7929
}