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.
Cheers,
Wincent
[1] http://wiki.tcl.tk/396
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
