gitk: Turn short SHA1 names into links too

Ok, so I'm a newbie when it comes to tcl/tk, but I can do copy-paste and make things work.

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.

This patch does seem to work, but it's also buggy in exactly the same ways the regular 40-character links are buggy, and while I find those bugs very irritating _too_, I can't cut-and-paste myself to a solution for that.

The pre-existing bugs that this shares with the long links are:

 - since gitk started doing incremental showing of the graph, the whole 
   "check if it exists" doesn't work right if the target hasn't been 
   loaded yet. And when it _does_ end up being loaded one second later, 
   nothing re-does the scanning.

   This is just a small irritation, but it's quite common when the first 
   commit that is displayed has a link. You can fix it by moving to the 
   next commit and moving right back (cursor-down + cursor-up), which will 
   re-display the commit and now find the link that wasn't available 
   initially, but it's still irritating.

   I think gitk could re-display the commit it is on when the whole list 
   of commits has been parsed, and at least then show the links it missed 
   initially after a few seconds.

 - slightly related to the above: when we _do_ find a link, we create it 
   to be a link to line so-and-so, but since we now don't just 
   incrementally parse the commits that come in, but gitk _also_ actually 
   reflows the commits to be in topological order, the link we just 
   created may actually no longer point to the right line by the time the 
   link is then clicked on, so clicking on a link can actually take you to 
   the wrong commit!

   Again, re-displaying the current commit after we have gotten and 
   parsed all commits will fix it, but this is a more fundamental problem: 
   if we redisplay at the end, there is still a window when the link may 
   simply be wrong, because we've redone the topo sort, but we haven't 
   seen _all_ commits yet.

   But again, you can work around it by going back and retrying, and at 
   some time it will stabilize. But this one is _really_ irritating when 
   it triggers, because it can make you look at the wrong commit without 
   necessarily realizing it was wrong!

I suspect that the correct fix is to always do the link, whether we actually see it or not, and not make it point to a line number, but simply keep it as a SHA1, and then do the equivalent of "gotocommit" when clicking it. But I don't know how links workin tcl/tk, so I'm not going to be able to do that.

In the meantime, this patch introduces no new bugs, and the workarounds are the same for abbreviated SHA1's as they are for the full ones.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---

I'm sure it could have been done better. In particular, I think the "short->long" translation could/should probably be a function of its own. But I'm so uncomfortable with wish programming that I'm not starting to write any new functions..

Comments? Paul?

			Linus

 gitk-git/gitk |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)