{"thread":{"id":"15679","subject":"gitk: Turn short SHA1 names into links too","startedAt":"2008-09-26T00:11:42Z","lastAt":"2008-10-21T19:09:00Z","messageCount":12,"participants":["Linus Torvalds","Wincent Colaiuta","Andreas Ericsson","Mikael Magnusson","Marco Costalba","Brad King","Paul Mackerras","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"91650","messageId":"alpine.LFD.1.10.0809251657080.3265@nehalem.linux-foundation.org","threadId":"15679","inReplyTo":null,"subject":"gitk: Turn short SHA1 names into links too","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-09-26T00:11:42Z","receivedAt":"2008-09-26T00:11:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOk, so I'm a newbie when it comes to tcl/tk, but I can do copy-paste and \nmake things work. \n\nAnd the thing I wanted to work was to have the abbreviated SHA1's that \nhave started to get more common in the kernel commit logs work as links in \ngitk too, just the way a full 40-character SHA1 link works.\n\nThis patch does seem to work, but it's also buggy in exactly the same ways \nthe regular 40-character links are buggy, and while I find those bugs \nvery irritating _too_, I can't cut-and-paste myself to a solution for \nthat.\n\nThe pre-existing bugs that this shares with the long links are:\n\n - since gitk started doing incremental showing of the graph, the whole \n \"check if it exists\" doesn't work right if the target hasn't been \n loaded yet. And when it _does_ end up being loaded one second later, \n nothing re-does the scanning.\n\n This is just a small irritation, but it's quite common when the first \n commit that is displayed has a link. You can fix it by moving to the \n next commit and moving right back (cursor-down + cursor-up), which will \n re-display the commit and now find the link that wasn't available \n initially, but it's still irritating.\n\n I think gitk could re-display the commit it is on when the whole list \n of commits has been parsed, and at least then show the links it missed \n initially after a few seconds.\n\n - slightly related to the above: when we _do_ find a link, we create it \n to be a link to line so-and-so, but since we now don't just \n incrementally parse the commits that come in, but gitk _also_ actually \n reflows the commits to be in topological order, the link we just \n created may actually no longer point to the right line by the time the \n link is then clicked on, so clicking on a link can actually take you to \n the wrong commit!\n\n Again, re-displaying the current commit after we have gotten and \n parsed all commits will fix it, but this is a more fundamental problem: \n if we redisplay at the end, there is still a window when the link may \n simply be wrong, because we've redone the topo sort, but we haven't \n seen _all_ commits yet.\n\n But again, you can work around it by going back and retrying, and at \n some time it will stabilize. But this one is _really_ irritating when \n it triggers, because it can make you look at the wrong commit without \n necessarily realizing it was wrong!\n\nI suspect that the correct fix is to always do the link, whether we \nactually see it or not, and not make it point to a line number, but simply \nkeep it as a SHA1, and then do the equivalent of \"gotocommit\" when \nclicking it. But I don't know how links workin tcl/tk, so I'm not going to \nbe able to do that.\n\nIn the meantime, this patch introduces no new bugs, and the workarounds \nare the same for abbreviated SHA1's as they are for the full ones.\n\nSigned-off-by: Linus Torvalds \n---\n\nI'm sure it could have been done better. In particular, I think the \n\"short->long\" translation could/should probably be a function of its own. \nBut I'm so uncomfortable with wish programming that I'm not starting to \nwrite any new functions..\n\nComments? Paul?\n\n\t\t\tLinus\n\n gitk-git/gitk | 15 +++++++++++++--\n 1 files changed, 13 insertions(+), 2 deletions(-)\n\ndiff --git a/gitk-git/gitk b/gitk-git/gitk\nindex 2eaa2ae..f79643a 100644\n--- a/gitk-git/gitk\n+++ b/gitk-git/gitk\n@@ -5759,7 +5759,7 @@ proc appendwithlinks {text tags} {\n \n set start [$ctext index \"end - 1c\"]\n $ctext insert end $text $tags\n- set links [regexp -indices -all -inline {[0-9a-f]{40}} $text]\n+ set links [regexp -indices -all -inline {[0-9a-f]{6,40}} $text]\n foreach l $links {\n \tset s [lindex $l 0]\n \tset e [lindex $l 1]\n@@ -5773,7 +5773,18 @@ proc appendwithlinks {text tags} {\n }\n \n proc setlink {id lk} {\n- global curview ctext pendinglinks commitinterest\n+ global curview ctext pendinglinks commitinterest varcid\n+\n+ # Turn a short ID into a full one\n+ if {[regexp {^[0-9a-f]{4,39}$} $id]} {\n+ set matches [array names varcid \"$curview,$id*\"]\n+ if {$matches ne {}} {\n+ if {[llength $matches] > 1} {\n+ return\n+ }\n+ set id [lindex [split [lindex $matches 0] \",\"] 1]\n+ }\n+ }\n \n if {[commitinview $id $curview]} {\n \t$ctext tag conf $lk -foreground blue -underline 1\n"},{"id":"91652","messageId":"alpine.LFD.1.10.0809251729440.3265@nehalem.linux-foundation.org","threadId":"15679","inReplyTo":"alpine.LFD.1.10.0809251657080.3265@nehalem.linux-foundation.org","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-09-26T00:37:10Z","receivedAt":"2008-09-26T00:37:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 25 Sep 2008, Linus Torvalds wrote:\n> \n> And the thing I wanted to work was to have the abbreviated SHA1's that \n> have started to get more common in the kernel commit logs work as links in \n> gitk too, just the way a full 40-character SHA1 link works.\n\nFor a test-case, I just pushed out my current top-of-tree that finally \npushed me over the edge. I've seen this before, but I couldn't really \nforce me to do anything about it until now.\n\nSo to see this in action, do\n\n\tgitk v2.6.26..6ef190c\n\non the current kernel repo, and notice that \"Commit ee1e2c82 (\"IPoIB: \nRefresh paths ..\" thing, where we want that 'ee1e2c82' to be a link even \nthough it's not a full SHA1.\n\nOf course, the matching could be better, it will now accept any random 6+ \ncharacter sequence of hex characters, even if they are surrounded by \ncharacters that make it clear that it's not a SHA1 (\"Haahahhaaaaaa!\" \nwould find the 'aaaaaa' and if you have a commit that starts with that, \nlink to it ;)\n\nAnd because it's the top commit, you can also easily see the behavior that \nit doesn't turn out to be a link immediately, and you have to do \ncursor-down + cursor-up to get the link. The \"it points to the wrong line\" \nbug is much harder to trigger, and possibly impossible with that \nparticular case (to trigger it, you need a setup where the first layout of \nthe target commit then gets changed by the topo-sort, I'm not sure that \nwill happen at all, and if it does, I'm not sure you could time it just \nright either, but I _have_ seen it in real life).\n\n\t\t\tLinus\n"},{"id":"91661","messageId":"BD7D0F18-32BD-4059-9190-A2C1B101B4C1@wincent.com","threadId":"15679","inReplyTo":"alpine.LFD.1.10.0809251729440.3265@nehalem.linux-foundation.org","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-09-26T06:32:19Z","receivedAt":"2008-09-26T06:32:19Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 26/9/2008, a las 2:37, Linus Torvalds escribió:\n\n> On Thu, 25 Sep 2008, Linus Torvalds wrote:\n>>\n>> And the thing I wanted to work was to have the abbreviated SHA1's \n>> that\n>> have started to get more common in the kernel commit logs work as \n>> links in\n>> gitk too, just the way a full 40-character SHA1 link works.\n>\n> For a test-case, I just pushed out my current top-of-tree that finally\n> pushed me over the edge. I've seen this before, but I couldn't really\n> force me to do anything about it until now.\n>\n> So to see this in action, do\n>\n> \tgitk v2.6.26..6ef190c\n>\n> on the current kernel repo, and notice that \"Commit ee1e2c82 (\"IPoIB:\n> Refresh paths ..\" thing, where we want that 'ee1e2c82' to be a link \n> even\n> though it's not a full SHA1.\n>\n> Of course, the matching could be better, it will now accept any \n> random 6+\n> character sequence of hex characters, even if they are surrounded by\n> characters that make it clear that it's not a SHA1 (\"Haahahhaaaaaa!\"\n> would find the 'aaaaaa' and if you have a commit that starts with \n> that,\n> link to it ;)\n\nI know nothing about tcl/tk, but will comment anyway:\n\nIt's a shame that tcl/tk regular expressions don't appear to support \nanchoring matches against word boundaries (ie. \"\\b\").\n\nIf so, a regexp like:\n\n [regexp {\\b[0-9a-f]{4,39}\\b} $id]\n\nwould mostly eliminate that kind of false positive. But from my \nreading of the wiki[1], looks like there's no \"\\b\" escape sequence. \nNor does it look like tcl/tk has support for lookahead/lookbehind \nassertions which could be used to the same effect.\n\n>\n\nCheers,\nWincent\n\n[1] http://wiki.tcl.tk/396\n"},{"id":"91663","messageId":"48DC8E91.6080909@op5.se","threadId":"15679","inReplyTo":"BD7D0F18-32BD-4059-9190-A2C1B101B4C1@wincent.com","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-09-26T07:26:09Z","receivedAt":"2008-09-26T07:26:09Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Wincent Colaiuta wrote:\n> El 26/9/2008, a las 2:37, Linus Torvalds escribió:\n> \n>> On Thu, 25 Sep 2008, Linus Torvalds wrote:\n>>>\n>>> And the thing I wanted to work was to have the abbreviated SHA1's that\n>>> have started to get more common in the kernel commit logs work as \n>>> links in\n>>> gitk too, just the way a full 40-character SHA1 link works.\n>>\n>> For a test-case, I just pushed out my current top-of-tree that finally\n>> pushed me over the edge. I've seen this before, but I couldn't really\n>> force me to do anything about it until now.\n>>\n>> So to see this in action, do\n>>\n>> gitk v2.6.26..6ef190c\n>>\n>> on the current kernel repo, and notice that \"Commit ee1e2c82 (\"IPoIB:\n>> Refresh paths ..\" thing, where we want that 'ee1e2c82' to be a link even\n>> though it's not a full SHA1.\n>>\n>> Of course, the matching could be better, it will now accept any random 6+\n>> character sequence of hex characters, even if they are surrounded by\n>> characters that make it clear that it's not a SHA1 (\"Haahahhaaaaaa!\"\n>> would find the 'aaaaaa' and if you have a commit that starts with that,\n>> link to it ;)\n> \n> I know nothing about tcl/tk, but will comment anyway:\n> \n> It's a shame that tcl/tk regular expressions don't appear to support \n> anchoring matches against word boundaries (ie. \"\\b\").\n> \n> If so, a regexp like:\n> \n> [regexp {\\b[0-9a-f]{4,39}\\b} $id]\n> \n> would mostly eliminate that kind of false positive. But from my reading \n> of the wiki[1], looks like there's no \"\\b\" escape sequence. Nor does it \n> look like tcl/tk has support for lookahead/lookbehind assertions which \n> could be used to the same effect.\n> \n\nIt's not as if this will be a real problem anyway. gitk is designed to\nbe used by humans, who can fortunately parse such things a trillion\ntimes better than any regex a billion monkeys could come up with in a\nbillion years, even if one was to take evolution into account. ;-)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"91664","messageId":"35256316-3297-4939-9F4E-2B2FBBE348BB@wincent.com","threadId":"15679","inReplyTo":"48DC8E91.6080909@op5.se","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-09-26T07:29:25Z","receivedAt":"2008-09-26T07:29:25Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 26/9/2008, a las 9:26, Andreas Ericsson escribió:\n\n> Wincent Colaiuta wrote:\n>> El 26/9/2008, a las 2:37, Linus Torvalds escribió:\n>>> On Thu, 25 Sep 2008, Linus Torvalds wrote:\n>>>>\n>>>> And the thing I wanted to work was to have the abbreviated SHA1's \n>>>> that\n>>>> have started to get more common in the kernel commit logs work as \n>>>> links in\n>>>> gitk too, just the way a full 40-character SHA1 link works.\n>>>\n>>> For a test-case, I just pushed out my current top-of-tree that \n>>> finally\n>>> pushed me over the edge. I've seen this before, but I couldn't \n>>> really\n>>> force me to do anything about it until now.\n>>>\n>>> So to see this in action, do\n>>>\n>>> gitk v2.6.26..6ef190c\n>>>\n>>> on the current kernel repo, and notice that \"Commit ee1e2c82 \n>>> (\"IPoIB:\n>>> Refresh paths ..\" thing, where we want that 'ee1e2c82' to be a \n>>> link even\n>>> though it's not a full SHA1.\n>>>\n>>> Of course, the matching could be better, it will now accept any \n>>> random 6+\n>>> character sequence of hex characters, even if they are surrounded by\n>>> characters that make it clear that it's not a SHA1 (\"Haahahhaaaaaa!\"\n>>> would find the 'aaaaaa' and if you have a commit that starts with \n>>> that,\n>>> link to it ;)\n>> I know nothing about tcl/tk, but will comment anyway:\n>> It's a shame that tcl/tk regular expressions don't appear to \n>> support anchoring matches against word boundaries (ie. \"\\b\").\n>> If so, a regexp like:\n>> [regexp {\\b[0-9a-f]{4,39}\\b} $id]\n>> would mostly eliminate that kind of false positive. But from my \n>> reading of the wiki[1], looks like there's no \"\\b\" escape sequence. \n>> Nor does it look like tcl/tk has support for lookahead/lookbehind \n>> assertions which could be used to the same effect.\n>\n> It's not as if this will be a real problem anyway. gitk is designed to\n> be used by humans, who can fortunately parse such things a trillion\n> times better than any regex a billion monkeys could come up with in a\n> billion years, even if one was to take evolution into account. ;-)\n\nOf course it's never going to be a _real_ problem (ie. a deal- \nbreaker), but most technical users will look on it as sloppy \nprogramming when the 'aaaaaa' in 'Haahahhaaaaaa!' gets turned into a \nlink.\n\nCheers,\nWincent\n"},{"id":"91668","messageId":"237967ef0809260121w1c7cc516tceb3be2cbebb85bc@mail.gmail.com","threadId":"15679","inReplyTo":"BD7D0F18-32BD-4059-9190-A2C1B101B4C1@wincent.com","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2008-09-26T08:21:45Z","receivedAt":"2008-09-26T08:21:45Z","isPatch":false,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2008/9/26 Wincent Colaiuta :\n> El 26/9/2008, a las 2:37, Linus Torvalds escribió:\n>\n>> On Thu, 25 Sep 2008, Linus Torvalds wrote:\n>>>\n>>> And the thing I wanted to work was to have the abbreviated SHA1's that\n>>> have started to get more common in the kernel commit logs work as links\n>>> in\n>>> gitk too, just the way a full 40-character SHA1 link works.\n>>\n>> For a test-case, I just pushed out my current top-of-tree that finally\n>> pushed me over the edge. I've seen this before, but I couldn't really\n>> force me to do anything about it until now.\n>>\n>> So to see this in action, do\n>>\n>> gitk v2.6.26..6ef190c\n>>\n>> on the current kernel repo, and notice that \"Commit ee1e2c82 (\"IPoIB:\n>> Refresh paths ..\" thing, where we want that 'ee1e2c82' to be a link even\n>> though it's not a full SHA1.\n>>\n>> Of course, the matching could be better, it will now accept any random 6+\n>> character sequence of hex characters, even if they are surrounded by\n>> characters that make it clear that it's not a SHA1 (\"Haahahhaaaaaa!\"\n>> would find the 'aaaaaa' and if you have a commit that starts with that,\n>> link to it ;)\n>\n> I know nothing about tcl/tk, but will comment anyway:\n>\n> It's a shame that tcl/tk regular expressions don't appear to support\n> anchoring matches against word boundaries (ie. \"\\b\").\n>\n> If so, a regexp like:\n>\n> [regexp {\\b[0-9a-f]{4,39}\\b} $id]\n>\n> would mostly eliminate that kind of false positive. But from my reading of\n> the wiki[1], looks like there's no \"\\b\" escape sequence. Nor does it look\n> like tcl/tk has support for lookahead/lookbehind assertions which could be\n> used to the same effect.\n\n\\y appears to achieve this;\n\n% regexp {abc\\y} 'abc'\n1\n% regexp {abc\\y} 'abcd'\n0\n% regexp {\\yabc\\y} 'uabc,d'\n0\n% regexp {\\yabc\\y} 'u+abc,d'\n1\n\nI have tcl/tk 8.5 so I cannot promise that isn't a new addition, I didn't\nlook it up anywhere, but it's \\y in some other implementations too, so I\ntried it.\n\n-- \nMikael Magnusson\n"},{"id":"91674","messageId":"e5bfff550809260341k1ac474c4j470594c53e916d2b@mail.gmail.com","threadId":"15679","inReplyTo":"BD7D0F18-32BD-4059-9190-A2C1B101B4C1@wincent.com","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-09-26T10:41:52Z","receivedAt":"2008-09-26T10:41:52Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Fri, Sep 26, 2008 at 8:32 AM, Wincent Colaiuta wrote:\n>\n> [regexp {\\b[0-9a-f]{4,39}\\b} $id]\n>\n> would mostly eliminate that kind of false positive.\n\nThis feature is already implemented in qgit from a long time. The most\ndifficult false positive I have found is the debug backtracing in the\nlog messages. Memory dumps are a big sources of false positives.\n"},{"id":"91677","messageId":"48DCD27E.6060704@kitware.com","threadId":"15679","inReplyTo":"237967ef0809260121w1c7cc516tceb3be2cbebb85bc@mail.gmail.com","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Brad King","fromEmail":"brad.king@kitware.com","sentAt":"2008-09-26T12:15:58Z","receivedAt":"2008-09-26T12:15:58Z","isPatch":false,"sender":{"key":"brad.king@kitware.com","avatar":"https://avatars.githubusercontent.com/u/87268?v=4"},"body":"Mikael Magnusson wrote:\n> 2008/9/26 Wincent Colaiuta :\n>> It's a shame that tcl/tk regular expressions don't appear to support\n>> anchoring matches against word boundaries (ie. \"\\b\").\n> \n> \\y appears to achieve this;\n> \n> % regexp {abc\\y} 'abc'\n> 1\n> % regexp {abc\\y} 'abcd'\n> 0\n> % regexp {\\yabc\\y} 'uabc,d'\n> 0\n> % regexp {\\yabc\\y} 'u+abc,d'\n> 1\n> \n> I have tcl/tk 8.5 so I cannot promise that isn't a new addition, I didn't\n> look it up anywhere, but it's \\y in some other implementations too, so I\n> tried it.\n\nIt goes back at least as far as tcl/tk 8.2:\n\nhttp://www.tcl.tk/man/tcl8.2.3/TclCmd/re_syntax.htm#M54\n\n-Brad\n"},{"id":"91726","messageId":"18653.42355.668715.736749@cargo.ozlabs.ibm.com","threadId":"15679","inReplyTo":"alpine.LFD.1.10.0809251657080.3265@nehalem.linux-foundation.org","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2008-09-27T03:16:03Z","receivedAt":"2008-09-27T03:16:03Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> And the thing I wanted to work was to have the abbreviated SHA1's that \n> have started to get more common in the kernel commit logs work as links in \n> gitk too, just the way a full 40-character SHA1 link works.\n\nFair enough...\n\n> This patch does seem to work, but it's also buggy in exactly the same ways \n> the regular 40-character links are buggy, and while I find those bugs \n> very irritating _too_, I can't cut-and-paste myself to a solution for \n> that.\n> \n> The pre-existing bugs that this shares with the long links are:\n> \n> - since gitk started doing incremental showing of the graph, the whole \n> \"check if it exists\" doesn't work right if the target hasn't been \n> loaded yet. And when it _does_ end up being loaded one second later, \n> nothing re-does the scanning.\n\nActually there *is* logic in gitk to remember that certain SHA1 ids\nare \"interesting\" and do something when we come across them later. So\nwhen we see a string of 40 hex digits in a commit message and we don't\nrecognize that as an ID that we know about, we remember it as an\ninteresting ID, with the action being to turn the string into a link.\nSo when the ID turns up later, the string in the commit message\nbecomes a link.\n\nHowever, that currently only works for the full 40-character IDs, not\nfor abbreviations, because the way we remember that the ID is\ninteresting is with an associative array (i.e. a hash). What we need\nto do is use only the first 6 characters and then have each array\nelement be a list of (ID, action) pairs, where the ID can now be a\npartial ID.\n\nI'd hack it up now except that I just got home from the US and I need\nto sleep...\n\n> - slightly related to the above: when we _do_ find a link, we create it \n> to be a link to line so-and-so, but since we now don't just \n> incrementally parse the commits that come in, but gitk _also_ actually \n> reflows the commits to be in topological order, the link we just \n> created may actually no longer point to the right line by the time the \n> link is then clicked on, so clicking on a link can actually take you to \n> the wrong commit!\n\nYep, guilty as charged. We need to defer the ID -> line number\ntranslation until the user actually clicks on the link.\n\n> I suspect that the correct fix is to always do the link, whether we \n> actually see it or not, and not make it point to a line number, but simply \n> keep it as a SHA1, and then do the equivalent of \"gotocommit\" when \n> clicking it. But I don't know how links workin tcl/tk, so I'm not going to \n> be able to do that.\n\nWe need this change in setlink (caution, completely untested):\n\n-\t$ctext tag bind $lk <1> [list selectline [rowofcommit $id] 1]\n+\t$ctext tag bind $lk <1> [list selbyid $id]\n\n> In the meantime, this patch introduces no new bugs, and the workarounds \n> are the same for abbreviated SHA1's as they are for the full ones.\n> \n> Signed-off-by: Linus Torvalds \n> ---\n> \n> I'm sure it could have been done better. In particular, I think the \n> \"short->long\" translation could/should probably be a function of its own. \n> But I'm so uncomfortable with wish programming that I'm not starting to \n> write any new functions..\n> \n> Comments? Paul?\n\nThe main thing is to change how we handle the commitinterest array so\nthat we can use it to match on short IDs as well as full 40-char ones.\nAnd yes, we should pull out the short->long translation into its own\nfunction.\n\nPaul.\n"},{"id":"91727","messageId":"18653.42476.355550.345797@cargo.ozlabs.ibm.com","threadId":"15679","inReplyTo":"BD7D0F18-32BD-4059-9190-A2C1B101B4C1@wincent.com","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2008-09-27T03:18:04Z","receivedAt":"2008-09-27T03:18:04Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Wincent Colaiuta writes:\n\n> It's a shame that tcl/tk regular expressions don't appear to support \n> anchoring matches against word boundaries (ie. \"\\b\").\n\nThey do. From the re_syntax (3tcl) man page:\n\n \\m matches only at the beginning of a word\n\n \\M matches only at the end of a word\n\n \\y matches only at the beginning or end of a word\n\n \\Y matches only at a point that is not the beginning or end of a\n word\n\nPaul.\n"},{"id":"93561","messageId":"18685.4652.287143.717452@cargo.ozlabs.ibm.com","threadId":"15679","inReplyTo":"alpine.LFD.1.10.0809251657080.3265@nehalem.linux-foundation.org","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2008-10-20T23:20:12Z","receivedAt":"2008-10-20T23:20:12Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> And the thing I wanted to work was to have the abbreviated SHA1's that \n> have started to get more common in the kernel commit logs work as links in \n> gitk too, just the way a full 40-character SHA1 link works.\n\nI just pushed out a commit to gitk that makes this work, and fixes the\nother bugs you mentioned.\n\nPaul.\n"},{"id":"93622","messageId":"7vzlkxyddf.fsf@gitster.siamese.dyndns.org","threadId":"15679","inReplyTo":"18685.4652.287143.717452@cargo.ozlabs.ibm.com","subject":"Re: gitk: Turn short SHA1 names into links too","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-21T19:09:00Z","receivedAt":"2008-10-21T19:09:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> Linus Torvalds writes:\n>\n>> And the thing I wanted to work was to have the abbreviated SHA1's that \n>> have started to get more common in the kernel commit logs work as links in \n>> gitk too, just the way a full 40-character SHA1 link works.\n>\n> I just pushed out a commit to gitk that makes this work, and fixes the\n> other bugs you mentioned.\n\nFWIW, pulled and pushed out. Thanks.\n"}]}