Re: gitk: Turn short SHA1 names into links too

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