Re: gitk: Turn short SHA1 names into links too

From: Wincent Colaiuta <win@wincent.com>
Date: Sep 26, 2008, 06:32 UTC
Message-ID: <BD7D0F18-32BD-4059-9190-A2C1B101B4C1@wincent.com>
In-Reply-To: <alpine.LFD.1.10.0809251729440.3265@nehalem.linux-foundation.org>

El 26/9/2008, a las 2:37, Linus Torvalds escribió:

Show 28 quoted lines

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

Cheers, Wincent

[1] http://wiki.tcl.tk/396