Re: gitk: Turn short SHA1 names into links too

> 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. ;-)