Re: gitk: Turn short SHA1 names into links too

[Linus Torvalds <torvalds@linux-foundation.org>]

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

And because it's the top commit, you can also easily see the behavior that 
it doesn't turn out to be a link immediately, and you have to do 
cursor-down + cursor-up to get the link. The "it points to the wrong line" 
bug is much harder to trigger, and possibly impossible with that 
particular case (to trigger it, you need a setup where the first layout of 
the target commit then gets changed by the topo-sort, I'm not sure that 
will happen at all, and if it does, I'm not sure you could time it just 
right either, but I _have_ seen it in real life).

			Linus