From: Wincent Colaiuta Date: Fri, 26 Sep 2008 07:29:25 GMT Subject: Re: gitk: Turn short SHA1 names into links too Message-ID: <35256316-3297-4939-9F4E-2B2FBBE348BB@wincent.com> In-Reply-To: <48DC8E91.6080909@op5.se> El 26/9/2008, a las 9:26, Andreas Ericsson escribió: > Wincent Colaiuta wrote: >> El 26/9/2008, a las 2:37, Linus Torvalds escribió: >>> On Thu, 25 Sep 2008, Linus Torvalds wrote: >>>> >>>> And the thing I wanted to work was to have the abbreviated SHA1's >>>> that >>>> have started to get more common in the kernel commit logs work as >>>> links in >>>> gitk too, just the way a full 40-character SHA1 link works. >>> >>> For a test-case, I just pushed out my current top-of-tree that >>> finally >>> pushed me over the edge. I've seen this before, but I couldn't >>> really >>> force me to do anything about it until now. >>> >>> So to see this in action, do >>> >>> gitk v2.6.26..6ef190c >>> >>> on the current kernel repo, and notice that "Commit ee1e2c82 >>> ("IPoIB: >>> Refresh paths .." thing, where we want that 'ee1e2c82' to be a >>> link even >>> though it's not a full SHA1. >>> >>> Of course, the matching could be better, it will now accept any >>> random 6+ >>> character sequence of hex characters, even if they are surrounded by >>> characters that make it clear that it's not a SHA1 ("Haahahhaaaaaa!" >>> would find the 'aaaaaa' and if you have a commit that starts with >>> that, >>> link to it ;) >> I know nothing about tcl/tk, but will comment anyway: >> It's a shame that tcl/tk regular expressions don't appear to >> support anchoring matches against word boundaries (ie. "\b"). >> If so, a regexp like: >> [regexp {\b[0-9a-f]{4,39}\b} $id] >> would mostly eliminate that kind of false positive. But from my >> reading of the wiki[1], looks like there's no "\b" escape sequence. >> Nor does it look like tcl/tk has support for lookahead/lookbehind >> assertions which could be used to the same effect. > > It's not as if this will be a real problem anyway. gitk is designed to > be used by humans, who can fortunately parse such things a trillion > times better than any regex a billion monkeys could come up with in a > billion years, even if one was to take evolution into account. ;-) Of course it's never going to be a _real_ problem (ie. a deal- breaker), but most technical users will look on it as sloppy programming when the 'aaaaaa' in 'Haahahhaaaaaa!' gets turned into a link. Cheers, Wincent