Re: gitk: Turn short SHA1 names into links too

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sep 26, 2008, 00:37 UTC
Message-ID: <alpine.LFD.1.10.0809251729440.3265@nehalem.linux-foundation.org>
In-Reply-To: <alpine.LFD.1.10.0809251657080.3265@nehalem.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