On Wed, Jun 16 2021, Junio C Hamano wrote: > "Rostislav Krasny via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> From: Rostislav Krasny <rosti.bsd@xxxxxxxxx> >> >> Signed-off-by: Rostislav Krasny <rosti.bsd@xxxxxxxxx> >> --- >> gitk: Add a basic support of SHA256 repositories into Gitk > > Looping-in the gitk maintainer. > >> This PR makes Gitk working on both SHA256 and SHA1 repositories without >> errors/crashes. I made it by changing and testing the gitk script of Git >> for Windows [https://gitforwindows.org/] version 2.32.0.windows.1 that >> is a little bit different than the mainstream 2.32.0 version. >> >> Still not fixed functionality: [1] There is the "Auto-select SHA1 >> (length)" configuration preference that affects "Copy commit reference" >> on both SHA1 and SHA256 repositories. >> >> A new "Auto-select SHA256 (length)" configuration preference should be >> added and used on SHA256 repositories instead of the old one. Since I'm >> not familiar with Tcl/Tk and this issue isn't critical I didn't >> implement it. > > Thanks, Rostislav; please follow Documentation/SubmittingPatches > next time you touch gitk (or git-gui), as they have their own > repositories and maintainers. A comment on the patch at large: I realize that the author isn't familiar with Tcl, and this is a minimal & immediate fix, so maybe we should just take it. But I wonder if this == 40 or == 64 shouldn't just be "accept either" in this case, these all seem like cases where we disambiguate a hash from some other name. Doing so would be nicely forward-compatible in case gitk and others ever need to deal with viewing a mixed set of hashes, or maybe I'm again misrecalling the transition plan and that'll never happen (they'll always be translated?). Especially stuff like this (grabbing a bit to quote from the patch): >> - if {[regexp {^[0-9a-f]{4,39}$} $id]} { >> + if {[regexp [string map "@@ [expr $hashlength - 1]" {^[0-9a-f]{4,@@}$}] $id]} { Would be simpler as just: if {[regexp {^[0-9a-f]{4,63}$} $id]} {
