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