From: Jeff Epler <hidden> Date: 2016-06-15 22:52:03
Many projects use project-specific notations in comments to refer to
bug trackers and the like. One example is the "Closes: #nnnnn"
notation used in Debian.
Make gitk configurable so that arbitrary strings can be turned into
clickable links that are opened in a web browser.
---
Some time ago I hardcoded this into gitk for $DAY_JOB and find it very
useful. I made it configurable in the hopes that it might be adopted
upstream. (unfortunately, the configurable version is radically
different from the original hard-coded version, so I can't say this
has had much testing yet)
The definition of the allowed regular expression in the docs
probably needs some refinement. Basically, they have to also be REs
that can be concatenated with the "|" character, which is not true
of REs that begin with the *** flavor selector (which I had not
heard of before rereading `man re_syntax` just now) or (?xyz)
embedded options. Or maybe there's an efficient alternate approach
to scanning for the next non-overlapping match among several
patterns that doesn't involve concatenating the patterns.
I'm not sure about the "one line" restriction; at first I thought
that everything was fed to 'appendwithlinks' in arbitrary chunks,
but not I see that they are mostly logical chunks (and probably only
the comment, not the headers or commit descriptors, will have
anything to linkify). The problem again seems to be how to succinctly
describe what is permitted.
There are probably better names for the configuration options, too.
Suggestions? Problems? Successes?
Jeff
Documentation/config.txt | 31 ++++++++++++++++++-
gitk-git/gitk | 74 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 102 insertions(+), 3 deletions(-)
@@ -1102,6 +1102,33 @@ All gitcvs variables except for 'gitcvs.usecrlfattr' and is one of "ext" and "pserver") to make them apply only for the given access method.+gitk.linkify.<name>.re::+ Specify a Tcl regular expression (which may not span lines)+ defining a class of strings to automatically convert to hyperlinks.+ You must also specify 'gitk.linkify.<name>.sub'.++gitk.linkify.<name>.sub::+ Specify a substitution that results in the target URL for the+ related regular expression. Back-references like '\1' refer+ to capturing groups in the associated regular expression.+ You must also specify 'gitk.linkify.<name>.re'.++gitk.browser::+ Specify the browser that will be used to display the linked+ web page.++For example, to automatically link from Debian-style "Closes: #nnnn"+message to the Debian BTS,++--------+ git config gitk.linkify.debian-bts.re 'Closes: #(\d+)'+ git config gitk.linkify.debian-bts.sub 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1'+--------++Regular expressions are as described in re_syntax(n). Replacements+are as described in regsub(n). If multiple regular expressions match at+the same location, it is undefined which match is used.+ grep.lineNumber:: If set to true, enable '-n' option by default.
@@ -1901,5 +1928,5 @@ user.signingkey:: web.browser:: Specify a web browser that may be used by some commands.- Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]- may use it.+ Currently only linkgit:git-instaweb[1], linkgit:gitk[1],+ and linkgit:git-help[1] may use it.
@@ -6684,7 +6684,7 @@ proc commit_descriptor {p} { # append some text to the ctext widget, and make any SHA1 ID # that we know about be a clickable link. proc appendwithlinks {text tags} {- global ctext linknum curview+ global ctext linknum curview linkmakers set start [$ctext index "end - 1c"] $ctext insert end $text $tags
@@ -6699,6 +6699,30 @@ proc appendwithlinks {text tags} { setlink $linkid link$linknum incr linknum }++ if {$linkmakers == {}} return++ set link_re {}+ foreach {re rep} $linkmakers { lappend link_re $re }+ set link_re "([join $link_re {)|(}])"++ set ee 0+ while {[regexp -indices -start $ee -- $link_re $text l]} {+ set s [lindex $l 0]+ set e [lindex $l 1]+ set linktext [string range $text $s $e]+ incr e+ set ee $e++ foreach {re rep} $linkmakers {+ if {![regsub $re $linktext $rep linkurl]} continue+ $ctext tag delete link$linknum+ $ctext tag add link$linknum "$start + $s c" "$start + $e c"+ seturllink $linkurl link$linknum+ incr linknum+ break+ }+ } } proc setlink {id lk} {
@@ -6726,6 +6750,52 @@ proc setlink {id lk} { } }+proc get_link_config {} {+ if {[catch {exec git config -z --get-regexp {^gitk\.linkify\.}} linkers]} {+ return {}+ }++ set linktypes [list]+ foreach item [split $linkers "\0"] {+ if {$item == ""} continue+ if {![regexp {gitk\.linkify\.(\S+)\.(re|sub)\s(.*)} $item _ k t v]} {+ continue+ }+ set linkconfig($t,$k) $v+ if {$t == "re"} { lappend linktypes $k }+ }++ set linkmakers [list]+ foreach k $linktypes {+ if {![info exists linkconfig(sub,$k)]} {+ puts stderr "Warning: link `$k' is missing a substitution string"+ } elseif {[catch {regexp -inline -- $linkconfig(re,$k) ""} err]} {+ puts stderr "Warning: link `$k': $err"+ } else {+ lappend linkmakers $linkconfig(re,$k) $linkconfig(sub,$k)+ }+ unset linkconfig(re,$k)+ unset -nocomplain linkconfig(sub,$k)+ }+ foreach k [array names linkconfig] {+ regexp "sub,(.*)" $k _ k+ puts stderr "Warning: link `$k' is missing a regular expression"+ }+ set linkmakers+}++proc openlink {url} {+ exec git web--browse --config=gitk.browser $url &+}++proc seturllink {url lk} {+ global ctext+ $ctext tag conf $lk -foreground blue -underline 1+ $ctext tag bind $lk <1> [list openlink $url]+ $ctext tag bind $lk <Enter> {linkcursor %W 1}+ $ctext tag bind $lk <Leave> {linkcursor %W -1}+}+ proc appendshortlink {id {pre {}} {post {}}} { global ctext linknum
From: Chris Packham <hidden> Date: 2016-06-15 22:52:03
Hi,
On 17/09/11 14:29, Jeff Epler wrote:
Some time ago I hardcoded this into gitk for $DAY_JOB and find it very
useful. I made it configurable in the hopes that it might be adopted
upstream. (unfortunately, the configurable version is radically
different from the original hard-coded version, so I can't say this
has had much testing yet)
This is definitely something folks at my $dayjob would be interested in.
We've already done some customisation of gitweb to do something similar.
I'm not actually sure what the changes where or how configurable they
are. I'll see if I can dig them out on Monday someone else might want to
polish them into something suitable (I might do it myself if I get some
tuits).
The definition of the allowed regular expression in the docs
probably needs some refinement. Basically, they have to also be REs
that can be concatenated with the "|" character, which is not true
of REs that begin with the *** flavor selector (which I had not
heard of before rereading `man re_syntax` just now) or (?xyz)
embedded options. Or maybe there's an efficient alternate approach
to scanning for the next non-overlapping match among several
patterns that doesn't involve concatenating the patterns.
I'm not sure about the "one line" restriction; at first I thought
that everything was fed to 'appendwithlinks' in arbitrary chunks,
but not I see that they are mostly logical chunks (and probably only
the comment, not the headers or commit descriptors, will have
anything to linkify). The problem again seems to be how to succinctly
describe what is permitted.
For my use case the one line restriction is fine. We tend to put the bug
number in the headline anyway.
Sometimes when a commit fixes multiple bugs we put all the bug numbers
in separated by commas. I don't know Tcl well enough to tell if your
code supports that or not.
There are probably better names for the configuration options, too.
It'd be nice if the config variables weren't gitk specific. .re and .sub
could be applied to gitweb and maybe other git viewers outside of
gig.git might decide to use them. My bikeshedding suggestion would be to
just drop the gitk prefix and have linkify.re and linkify.sub.
Suggestions? Problems? Successes?
Re-compiling now. I won't be able to actually test it properly until I'm
back in the office but I can at least check that the links are generated.
From: Chris Packham <hidden> Date: 2016-06-15 22:52:03
On 17/09/11 21:26, Chris Packham wrote:
Hi,
On 17/09/11 14:29, Jeff Epler wrote:
quoted
Some time ago I hardcoded this into gitk for $DAY_JOB and find it very
useful. I made it configurable in the hopes that it might be adopted
upstream. (unfortunately, the configurable version is radically
different from the original hard-coded version, so I can't say this
has had much testing yet)
This is definitely something folks at my $dayjob would be interested in.
We've already done some customisation of gitweb to do something similar.
I'm not actually sure what the changes where or how configurable they
are. I'll see if I can dig them out on Monday someone else might want to
polish them into something suitable (I might do it myself if I get some
tuits).
quoted
The definition of the allowed regular expression in the docs
probably needs some refinement. Basically, they have to also be REs
that can be concatenated with the "|" character, which is not true
of REs that begin with the *** flavor selector (which I had not
heard of before rereading `man re_syntax` just now) or (?xyz)
embedded options. Or maybe there's an efficient alternate approach
to scanning for the next non-overlapping match among several
patterns that doesn't involve concatenating the patterns.
I'm not sure about the "one line" restriction; at first I thought
that everything was fed to 'appendwithlinks' in arbitrary chunks,
but not I see that they are mostly logical chunks (and probably only
the comment, not the headers or commit descriptors, will have
anything to linkify). The problem again seems to be how to succinctly
describe what is permitted.
For my use case the one line restriction is fine. We tend to put the bug
number in the headline anyway.
Sometimes when a commit fixes multiple bugs we put all the bug numbers
in separated by commas. I don't know Tcl well enough to tell if your
code supports that or not.
quoted
There are probably better names for the configuration options, too.
It'd be nice if the config variables weren't gitk specific. .re and .sub
could be applied to gitweb and maybe other git viewers outside of
gig.git might decide to use them. My bikeshedding suggestion would be to
just drop the gitk prefix and have linkify.re and linkify.sub.
That should be linkify.<name>.re and linkify.<name>.sub
quoted
Suggestions? Problems? Successes?
Re-compiling now. I won't be able to actually test it properly until I'm
back in the office but I can at least check that the links are generated.
Slight complication. The URL of our bug tracker has an ampersand '&' in
it. Tcl's substitution does what one might expect and puts the matched
text where the '&' is. I've tried using url friendly %26 but something
eats the %. I've also tried backslashes to no avail.
To answer my own question since I started writing this email I've found
that using %% works (only the first one gets eaten). Not sure if that's
expected behaviour or not (printf escaping maybe?).
Also since I've been playing around I've tried a commit with multiple
bug numbers on one line and that works as expected.
Thanks
Chris
From: Jeff Epler <hidden> Date: 2016-06-15 22:52:03
quoted
There are probably better names for the configuration options, too.
It'd be nice if the config variables weren't gitk specific. .re and .sub
could be applied to gitweb and maybe other git viewers outside of
gig.git might decide to use them. My bikeshedding suggestion would be to
just drop the gitk prefix and have linkify.re and linkify.sub.
This seems like a reasonable idea, though since the implementation
languages of gitk and gitweb are different it means some REs might get
different interpretations in the different programs.
Sometimes when a commit fixes multiple bugs we put all the bug numbers
in separated by commas. I don't know Tcl well enough to tell if your
code supports that or not.
Multiple matches per line are OK, but they must be non-overlapping.
Looking at the actual practice in Debian changelogs, I see that they do
this:
evince/changelog.Debian.gz: (Closes: #388368, #396467, #405130)
so my original example would only linkify "Closes: #388638". But a
revised pattern of #(\d+) would linkify "#388368", "#396467" and "#405130".
(but risk a few more "false positive" links). I should revise my
example accordingly.
As for the problems with your substitutions, "&" is special in a tcl
regsub (it stands for the whole matched string, like \0), so you'd want
to use a substitution like
git config gitk.linkify.debian-bts.sub \
'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1\&foo=bar'
The problem with "%" has to do with Tk's event substitution and it's a
bug that this happens; I should manually double the % at the proper
point.
This revised patch fixes the problem with % in substitutions and changes
the suggested RE for matching debian bts items, but it does not rename
the configuration options.
-- >8 --
Many projects use project-specific notations in changelogs to refer
to bug trackers and the like. One example is the "Closes: #12345"
notation used in Debian.
Make gitk configurable so that arbitrary strings can be turned into
clickable links that are opened in a web browser.
---
Documentation/config.txt | 31 ++++++++++++++++++-
gitk-git/gitk | 75 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 103 insertions(+), 3 deletions(-)
@@ -1064,6 +1064,33 @@ All gitcvs variables except for 'gitcvs.usecrlfattr' and is one of "ext" and "pserver") to make them apply only for the given access method.+gitk.linkify.<name>.re::+ Specify a Tcl regular expression (which may not span lines)+ defining a class of strings to automatically convert to hyperlinks.+ You must also specify 'gitk.linkify.<name>.sub'.++gitk.linkify.<name>.sub::+ Specify a substitution that results in the target URL for the+ related regular expression. Back-references like '\1' refer+ to capturing groups in the associated regular expression.+ You must also specify 'gitk.linkify.<name>.re'.++gitk.browser::+ Specify the browser that will be used to display the linked+ web page.++For example, to automatically link from Debian-style "Closes: #nnnn"+message to the Debian BTS,++--------+ git config gitk.linkify.debian-bts.re '#(\d+)\M'+ git config gitk.linkify.debian-bts.sub 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1'+--------++Regular expressions are as described in re_syntax(n). Replacements+are as described in regsub(n). If multiple regular expressions match at+the same location, it is undefined which match is used.+ grep.lineNumber:: If set to true, enable '-n' option by default.
@@ -1870,5 +1897,5 @@ user.signingkey:: web.browser:: Specify a web browser that may be used by some commands.- Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]- may use it.+ Currently only linkgit:git-instaweb[1], linkgit:gitk[1],+ and linkgit:git-help[1] may use it.
@@ -6684,7 +6684,7 @@ proc commit_descriptor {p} { # append some text to the ctext widget, and make any SHA1 ID # that we know about be a clickable link. proc appendwithlinks {text tags} {- global ctext linknum curview+ global ctext linknum curview linkmakers set start [$ctext index "end - 1c"] $ctext insert end $text $tags
@@ -6699,6 +6699,30 @@ proc appendwithlinks {text tags} { setlink $linkid link$linknum incr linknum }++ if {$linkmakers == {}} return++ set link_re {}+ foreach {re rep} $linkmakers { lappend link_re $re }+ set link_re "([join $link_re {)|(}])"++ set ee 0+ while {[regexp -indices -start $ee -- $link_re $text l]} {+ set s [lindex $l 0]+ set e [lindex $l 1]+ set linktext [string range $text $s $e]+ incr e+ set ee $e++ foreach {re rep} $linkmakers {+ if {![regsub $re $linktext $rep linkurl]} continue+ $ctext tag delete link$linknum+ $ctext tag add link$linknum "$start + $s c" "$start + $e c"+ seturllink $linkurl link$linknum+ incr linknum+ break+ }+ } } proc setlink {id lk} {
@@ -6726,6 +6750,53 @@ proc setlink {id lk} { } }+proc get_link_config {} {+ if {[catch {exec git config -z --get-regexp {^gitk\.linkify\.}} linkers]} {+ return {}+ }++ set linktypes [list]+ foreach item [split $linkers "\0"] {+ if {$item == ""} continue+ if {![regexp {gitk\.linkify\.(\S+)\.(re|sub)\s(.*)} $item _ k t v]} {+ continue+ }+ set linkconfig($t,$k) $v+ if {$t == "re"} { lappend linktypes $k }+ }++ set linkmakers [list]+ foreach k $linktypes {+ if {![info exists linkconfig(sub,$k)]} {+ puts stderr "Warning: link `$k' is missing a substitution string"+ } elseif {[catch {regexp -inline -- $linkconfig(re,$k) ""} err]} {+ puts stderr "Warning: link `$k': $err"+ } else {+ lappend linkmakers $linkconfig(re,$k) $linkconfig(sub,$k)+ }+ unset linkconfig(re,$k)+ unset -nocomplain linkconfig(sub,$k)+ }+ foreach k [array names linkconfig] {+ regexp "sub,(.*)" $k _ k+ puts stderr "Warning: link `$k' is missing a regular expression"+ }+ set linkmakers+}++proc openlink {url} {+ exec git web--browse --config=gitk.browser $url &+}++proc seturllink {url lk} {+ set qurl [string map {% %%} $url]+ global ctext+ $ctext tag conf $lk -foreground blue -underline 1+ $ctext tag bind $lk <1> [list openlink $qurl]+ $ctext tag bind $lk <Enter> {linkcursor %W 1}+ $ctext tag bind $lk <Leave> {linkcursor %W -1}+}+ proc appendshortlink {id {pre {}} {post {}}} { global ctext linknum
From: Chris Packham <hidden> Date: 2016-06-15 22:52:03
On 18/09/11 01:45, Jeff Epler wrote:
quoted
quoted
There are probably better names for the configuration options, too.
It'd be nice if the config variables weren't gitk specific. .re and .sub
could be applied to gitweb and maybe other git viewers outside of
gig.git might decide to use them. My bikeshedding suggestion would be to
just drop the gitk prefix and have linkify.re and linkify.sub.
This seems like a reasonable idea, though since the implementation
languages of gitk and gitweb are different it means some REs might get
different interpretations in the different programs.
quoted
Sometimes when a commit fixes multiple bugs we put all the bug numbers
in separated by commas. I don't know Tcl well enough to tell if your
code supports that or not.
Multiple matches per line are OK, but they must be non-overlapping.
Looking at the actual practice in Debian changelogs, I see that they do
this:
evince/changelog.Debian.gz: (Closes: #388368, #396467, #405130)
so my original example would only linkify "Closes: #388638". But a
revised pattern of #(\d+) would linkify "#388368", "#396467" and "#405130".
(but risk a few more "false positive" links). I should revise my
example accordingly.
As for the problems with your substitutions, "&" is special in a tcl
regsub (it stands for the whole matched string, like \0), so you'd want
to use a substitution like
git config gitk.linkify.debian-bts.sub \
'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1\&foo=bar'
Hmm no joy with \&. Seems to upset the invocation of git web-browse
git config gitk.linkify.bugtracker.sub \
'https://internalhost/code\&stuff/bugs.php?id=\1'
gitk
/home/chrisp/libexec/git-core/git-web--browse: line 167:
stuff/bugs.php?id=bug123: No such file or directory
fatal: 'web--browse' appears to be a git command, but we were not
able to execute it. Maybe git-web--browse is broken?
Using the following works as expected with no error with your updated patch.
git config gitk.linkify.bugtracker.sub \
'https://internalhost/code%26stuff/bugs.php?id=\1'
The problem with "%" has to do with Tk's event substitution and it's a
bug that this happens; I should manually double the % at the proper
point.
From: Chris Packham <hidden> Date: 2016-06-15 22:52:03
On 18/09/11 11:33, Chris Packham wrote:
On 18/09/11 01:45, Jeff Epler wrote:
quoted
quoted
quoted
There are probably better names for the configuration options, too.
It'd be nice if the config variables weren't gitk specific. .re and .sub
could be applied to gitweb and maybe other git viewers outside of
gig.git might decide to use them. My bikeshedding suggestion would be to
just drop the gitk prefix and have linkify.re and linkify.sub.
This seems like a reasonable idea, though since the implementation
languages of gitk and gitweb are different it means some REs might get
different interpretations in the different programs.
quoted
Sometimes when a commit fixes multiple bugs we put all the bug numbers
in separated by commas. I don't know Tcl well enough to tell if your
code supports that or not.
Multiple matches per line are OK, but they must be non-overlapping.
Looking at the actual practice in Debian changelogs, I see that they do
this:
evince/changelog.Debian.gz: (Closes: #388368, #396467, #405130)
so my original example would only linkify "Closes: #388638". But a
revised pattern of #(\d+) would linkify "#388368", "#396467" and "#405130".
(but risk a few more "false positive" links). I should revise my
example accordingly.
As for the problems with your substitutions, "&" is special in a tcl
regsub (it stands for the whole matched string, like \0), so you'd want
to use a substitution like
git config gitk.linkify.debian-bts.sub \
'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1\&foo=bar'
Hmm no joy with \&. Seems to upset the invocation of git web-browse
git config gitk.linkify.bugtracker.sub \
'https://internalhost/code\&stuff/bugs.php?id=\1'
gitk
/home/chrisp/libexec/git-core/git-web--browse: line 167:
stuff/bugs.php?id=bug123: No such file or directory
fatal: 'web--browse' appears to be a git command, but we were not
able to execute it. Maybe git-web--browse is broken?
This is probably a issue with git web--browse and nothing to do with
your changes.
Sure enough this works fine
git web--browse --browser=firefox \
https://internalhost/code\&stuff/bugs.php?id=foo
While this doesn't
git web--browse https://internalhost/code\&stuff/bugs.php?id=foo
/home/chrisp/libexec/git-core/git-web--browse: line 167:
stuff/bugs.php?id=foo: No such file or directory
fatal: 'web--browse' appears to be a git command, but we were not
able to execute it. Maybe git-web--browse is broken?
Neither does this
git web--browse --browser=konqueror \
https://internalhost/code\&stuff/bugs.php?id=foo
A little bit more info that might help diagnose the issue - I'm running
openSUSE 11.4 (kde 4.6) which ships with firefox set as the default web
browser so 'kfmclient newTab http://www.example.com' actually opens firefox.
However trying kfmclient with my funny URL still works
kfmclient newTab https://internalhost/code\&stuff/bugs.php?id=foo
I'm a little stumped as to what is going wrong in git web--browse.
From: Chris Packham <hidden> Date: 2016-06-15 22:52:03
On 18/09/11 12:30, Chris Packham wrote:
On 18/09/11 11:33, Chris Packham wrote:
quoted
On 18/09/11 01:45, Jeff Epler wrote:
quoted
quoted
quoted
There are probably better names for the configuration options, too.
It'd be nice if the config variables weren't gitk specific. .re and .sub
could be applied to gitweb and maybe other git viewers outside of
gig.git might decide to use them. My bikeshedding suggestion would be to
just drop the gitk prefix and have linkify.re and linkify.sub.
This seems like a reasonable idea, though since the implementation
languages of gitk and gitweb are different it means some REs might get
different interpretations in the different programs.
quoted
Sometimes when a commit fixes multiple bugs we put all the bug numbers
in separated by commas. I don't know Tcl well enough to tell if your
code supports that or not.
Multiple matches per line are OK, but they must be non-overlapping.
Looking at the actual practice in Debian changelogs, I see that they do
this:
evince/changelog.Debian.gz: (Closes: #388368, #396467, #405130)
so my original example would only linkify "Closes: #388638". But a
revised pattern of #(\d+) would linkify "#388368", "#396467" and "#405130".
(but risk a few more "false positive" links). I should revise my
example accordingly.
As for the problems with your substitutions, "&" is special in a tcl
regsub (it stands for the whole matched string, like \0), so you'd want
to use a substitution like
git config gitk.linkify.debian-bts.sub \
'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1\&foo=bar'
Hmm no joy with \&. Seems to upset the invocation of git web-browse
git config gitk.linkify.bugtracker.sub \
'https://internalhost/code\&stuff/bugs.php?id=\1'
gitk
/home/chrisp/libexec/git-core/git-web--browse: line 167:
stuff/bugs.php?id=bug123: No such file or directory
fatal: 'web--browse' appears to be a git command, but we were not
able to execute it. Maybe git-web--browse is broken?
This is probably a issue with git web--browse and nothing to do with
your changes.
Sure enough this works fine
git web--browse --browser=firefox \
https://internalhost/code\&stuff/bugs.php?id=foo
While this doesn't
git web--browse https://internalhost/code\&stuff/bugs.php?id=foo
/home/chrisp/libexec/git-core/git-web--browse: line 167:
stuff/bugs.php?id=foo: No such file or directory
fatal: 'web--browse' appears to be a git command, but we were not
able to execute it. Maybe git-web--browse is broken?
Neither does this
git web--browse --browser=konqueror \
https://internalhost/code\&stuff/bugs.php?id=foo
A little bit more info that might help diagnose the issue - I'm running
openSUSE 11.4 (kde 4.6) which ships with firefox set as the default web
browser so 'kfmclient newTab http://www.example.com' actually opens firefox.
However trying kfmclient with my funny URL still works
kfmclient newTab https://internalhost/code\&stuff/bugs.php?id=foo
I'm a little stumped as to what is going wrong in git web--browse.
Hmm. The offending lines look like:
eval "$browser_path" "$@" &
Normally in git we treat user-configured commands as shell snippets,
meaning the user is responsible for any quoting. But in this script, we
seem to run:
type "$browser_path"
several times. Which implies that "$browser_path" must be the actual
executable. In which case, I would think that:
"$browser_path" "$@" &
would be the right thing. And indeed, that is what the firefox arm of
the case statement does. But chrome, konqueror, and others use eval.
Unrelated, but it also looks like $browser_path is used unquoted in the
firefox case (see inside the vers=$(...)).
-Peff
From: Chris Packham <hidden> Date: 2016-06-15 22:52:03
Instead of using eval which causes problems when a URL contains an
appropriately escaped ampersand (\&).
Cc: peff@peff.net
Cc: chriscool@tuxfamily.org
Cc: jepler@unpythonic.net
Signed-off-by: Chris Packham <redacted>
---
Which implies that "$browser_path" must be the actual
executable. In which case, I would think that:
"$browser_path" "$@" &
would be the right thing. And indeed, that is what the firefox arm of
the case statement does. But chrome, konqueror, and others use eval.
So here is my attempt at a fix for kfmclient.
For what it's worth I've included a testcase that detects my problem. I'm not
sure if the testcase is really worth it because the test library suppresses X
applications and even if it didn't the testcase is fairly trivial and might
just annoy people by opening web-browsers (and it snaps up the last t99xx
prefix).
git-web--browse.sh | 4 ++--
t/t9901-git-web--browse.sh | 43 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 2 deletions(-)
create mode 100755 t/t9901-git-web--browse.sh
@@ -164,10 +164,10 @@ konqueror)# It's simpler to use kfmclient to open a new tab in konqueror.browser_path="$(echo"$browser_path"|sed-e's/konqueror$/kfmclient/')"type"$browser_path">/dev/null2>&1||die"No '$browser_path' found."-eval"$browser_path"newTab"$@"+"$browser_path"newTab"$@"&;;kfmclient)-eval"$browser_path"newTab"$@"+"$browser_path"newTab"$@"&;;*)"$browser_path""$@"&
@@ -0,0 +1,43 @@+#!/bin/sh+#+# Copyright (c) 2011 Chris Packham+#++test_description='gitweb--browsebasictests++Thistestchecksthatgitweb--browsecanhandlevariousvalidURLswith+thesupportedbrowsersthatareinstalledonthehostsystem.'++../test-lib.sh++test-x/usr/bin/firefox&&test_set_prereqFIREFOX+test-x/usr/bin/konqueror&&test_set_prereqKONQUEROR+test-x/usr/bin/google-chrome&&test_set_prereqCHROME+test-x/usr/bin/opera&&test_set_prereqOPERA++test_expect_success\+'accepts a URL with an ampersand in it (default)''+gitweb--browsehttp://example.com/foo\&bar/+'++test_expect_successFIREFOX\+'accepts a URL with an ampersand in it (firefox)''+gitweb--browse--browser=firefoxhttp://example.com/foo\&bar/+'++test_expect_successKONQUEROR\+'accepts a URL with an ampersand in it (konqueror)''+gitweb--browse--browser=konquerorhttp://example.com/foo\&bar/+'++test_expect_successOPERA\+'accepts a URL with an ampersand in it (opera)''+gitweb--browse--browser=operahttp://example.com/foo\&bar/+'++test_expect_successCHROME\+'accepts a URL with an ampersand in it (chrome)''+gitweb--browse--browser=google-chromehttp://example.com/foo\&bar/+'++test_done
Hmm. The offending lines look like:
eval "$browser_path" "$@" &
Normally in git we treat user-configured commands as shell snippets,
meaning the user is responsible for any quoting. But in this script, we
seem to run:
type "$browser_path"
several times. Which implies that "$browser_path" must be the actual
executable. In which case, I would think that:
"$browser_path" "$@" &
would be the right thing. And indeed, that is what the firefox arm of
the case statement does. But chrome, konqueror, and others use eval.
Yeah, I don't remember why I sometimes used 'eval "$browser_path" "$@"' when I
wrote this code. Sorry!
Unrelated, but it also looks like $browser_path is used unquoted in the
firefox case (see inside the vers=$(...)).
From: Jeff King <hidden> Date: 2016-06-15 22:52:03
On Sun, Sep 18, 2011 at 10:20:24PM +1200, Chris Packham wrote:
Instead of using eval which causes problems when a URL contains an
appropriately escaped ampersand (\&).
I think this probably should just remove all of the evals. I don't see
how any of them is doing any good, and they're actively breaking URLs
that need quoting.
Hmm. Actually, the one for custom browser commands might need it,
because that one is expected to be a shell snippet. I suspect the
simplest thing is to do something like:
eval "$browser_cmd \"\$@\""
The other option would be to actually shell-quote each argument, which
is a pain to do in the shell (but is what C git does).
For what it's worth I've included a testcase that detects my problem. I'm not
sure if the testcase is really worth it because the test library suppresses X
applications and even if it didn't the testcase is fairly trivial and might
just annoy people by opening web-browsers (and it snaps up the last t99xx
prefix).
Ick, yeah. Actually starting real browsers interacts too much with the
world outside of the test scripts. The results will be annoying (new
browser windows) and cause non-deterministic test results.
If you want to make a test, I think you would do better with something
like:
echo someurl_with_&_in_it >expect &&
git config browser.custom.cmd echo &&
git web--browse --browser=custom someurl_with_&_in_it >actual &&
test_cmp expect actual
That won't test that we are invoking kfmclient correctly, obviously, but
you can confirm at least that URLs are making it through to the browser
script intact.
-Peff
From: Jakub Narebski <hidden> Date: 2016-06-15 22:52:03
Chris Packham [off-list ref] writes:
On 17/09/11 14:29, Jeff Epler wrote:
quoted
Some time ago I hardcoded this into gitk for $DAY_JOB and find it very
useful. I made it configurable in the hopes that it might be adopted
upstream. (unfortunately, the configurable version is radically
different from the original hard-coded version, so I can't say this
has had much testing yet)
This is definitely something folks at my $dayjob would be interested in.
We've already done some customisation of gitweb to do something similar.
I'm not actually sure what the changes where or how configurable they
are. I'll see if I can dig them out on Monday someone else might want to
polish them into something suitable (I might do it myself if I get some
tuits).
That would be nice. So called "committags" support was long planned
for gitweb, and even some preliminary work exists...
quoted
There are probably better names for the configuration options, too.
It'd be nice if the config variables weren't gitk specific. .re and .sub
could be applied to gitweb and maybe other git viewers outside of
gig.git might decide to use them. My bikeshedding suggestion would be to
just drop the gitk prefix and have linkify.re and linkify.sub.
Perhaps more descriptive name, i.e.
linkify.<name>.regexp
linkify.<name>.subst
would be better?
I guess that regexp is an extended regular expression, isn't it?
--
Jakub Narębski
From: Chris Packham <hidden> Date: 2016-06-15 22:52:04
Using eval causes problems when the URL contains an appropriately
escaped ampersand (\&). Dropping eval from the built-in browser
invocation avoids the problem.
Cc: peff@peff.net
Cc: chriscool@tuxfamily.org
Cc: jepler@unpythonic.net
Signed-off-by: Chris Packham <redacted>
---
Here's an updated patch which drops the uses of eval when invoking a
supported browser. The default case still uses eval but adds some extra
quoting which also fixes the problem. I've avoided touching the 'start'
case because I don't have access to a windows system to test with.
I've replaced my tests With the test suggested by Peff (should I be
giving him credit in the copyright line or something?). I've grabbed
t9901 but if there is a better set of miscellaneous minor tests that I
should be using let me know.
git-web--browse.sh | 10 +++++-----
t/t9901-git-web--browse.sh | 21 +++++++++++++++++++++
2 files changed, 26 insertions(+), 5 deletions(-)
create mode 100755 t/t9901-git-web--browse.sh
@@ -156,7 +156,7 @@ firefox|iceweasel|seamonkey|iceape);; google-chrome|chrome|chromium|chromium-browser)# No need to specify newTab. It's default in chromium-eval"$browser_path""$@"&+"$browser_path""$@"&;; konqueror)case"$(basename"$browser_path")"in
@@ -164,10 +164,10 @@ konqueror)# It's simpler to use kfmclient to open a new tab in konqueror.browser_path="$(echo"$browser_path"|sed-e's/konqueror$/kfmclient/')"type"$browser_path">/dev/null2>&1||die"No '$browser_path' found."-eval"$browser_path"newTab"$@"+"$browser_path"newTab"$@"&;;kfmclient)-eval"$browser_path"newTab"$@"+"$browser_path"newTab"$@"&;;*)"$browser_path""$@"&
@@ -0,0 +1,21 @@+#!/bin/sh+#+# Copyright (c) 2011 Chris Packham+#++test_description='gitweb--browsebasictests++Thistestchecksthatgitweb--browsecanhandlevariousvalidURLs.'++../test-lib.sh++test_expect_success\+'accepts a URL with an ampersand in it''+echohttp://example.com/foo\&bar/>expect&&+gitconfigbrowser.custom.cmdecho&&+gitweb--browse--browser=custom\+http://example.com/foo\&bar/>actual&&+test_cmpexpectactual+'++test_done
From: Marc Branchaud <hidden> Date: 2016-06-15 22:52:04
On 11-09-17 07:33 PM, Chris Packham wrote:
Hmm no joy with \&. Seems to upset the invocation of git web-browse
git config gitk.linkify.bugtracker.sub \
'https://internalhost/code\&stuff/bugs.php?id=\1'
gitk
/home/chrisp/libexec/git-core/git-web--browse: line 167:
stuff/bugs.php?id=bug123: No such file or directory
fatal: 'web--browse' appears to be a git command, but we were not
able to execute it. Maybe git-web--browse is broken?
Using the following works as expected with no error with your updated patch.
git config gitk.linkify.bugtracker.sub \
'https://internalhost/code%26stuff/bugs.php?id=\1'
Jeff: This is great -- thanks!
I still had problems with using an & in the URL, even with the updated patch.
I had to apply Chris's git-web--browse patch to get it to work.
M.
From: Jeff King <hidden> Date: 2016-06-15 22:52:04
On Mon, Sep 19, 2011 at 09:26:55PM +1200, Chris Packham wrote:
Using eval causes problems when the URL contains an appropriately
escaped ampersand (\&). Dropping eval from the built-in browser
invocation avoids the problem.
Cc: peff@peff.net
Cc: chriscool@tuxfamily.org
Cc: jepler@unpythonic.net
Although other projects do use "cc" in the commit message, I think we
don't usually bother adding this noise in the git project. The cc
headers in your email are enough.
I've replaced my tests With the test suggested by Peff (should I be
giving him credit in the copyright line or something?).
For a minor bit of help, usually mentioning the person in the commit
message (with a "Helped-by", or indicating which parts they contributed
to) is plenty. Personally, I don't even care much about that. My
contributions to git are thoroughly documented in the commit history and
the mailing list at this point. :)
I also find the "Copyright ..." lines in the files to be overkill, too.
They end up becoming out-of-date as other people work on the file. The
commit history is the best way to get the right answer, and a comment in
the file is at best redundant with what's there. But that is just my
opinion; I don't know that we have a particular policy for such
things[1].
-Peff
[1] Once upon a time, I think I saw the advice that every file should
have a copyright notice and mention the license at the top of the file,
but I don't know that it has ever been tested in court. I suppose the
distributed tarballs of a particular version would lack the copyright
attribution, but in that case, my solution would be to generate it from
the commit history at packaging time.
From: Chris Packham <hidden> Date: 2016-06-15 22:52:04
On 20/09/11 06:34, Jeff King wrote:
On Mon, Sep 19, 2011 at 09:26:55PM +1200, Chris Packham wrote:
quoted
Using eval causes problems when the URL contains an appropriately
escaped ampersand (\&). Dropping eval from the built-in browser
invocation avoids the problem.
Cc: peff@peff.net
Cc: chriscool@tuxfamily.org
Cc: jepler@unpythonic.net
Although other projects do use "cc" in the commit message, I think we
don't usually bother adding this noise in the git project. The cc
headers in your email are enough.
That's more for git send-email's benefit than anything else. I'm working
on a laptop with a touchpad (and a cat) so the less switching between
editor and MUA the better. Any better suggestions for tracking Cc's for
git send-email?
quoted
I've replaced my tests With the test suggested by Peff (should I be
giving him credit in the copyright line or something?).
For a minor bit of help, usually mentioning the person in the commit
message (with a "Helped-by", or indicating which parts they contributed
to) is plenty. Personally, I don't even care much about that. My
contributions to git are thoroughly documented in the commit history and
the mailing list at this point. :)
I also find the "Copyright ..." lines in the files to be overkill, too.
They end up becoming out-of-date as other people work on the file. The
commit history is the best way to get the right answer, and a comment in
the file is at best redundant with what's there. But that is just my
opinion; I don't know that we have a particular policy for such
things[1].
-Peff
[1] Once upon a time, I think I saw the advice that every file should
have a copyright notice and mention the license at the top of the file,
but I don't know that it has ever been tested in court. I suppose the
distributed tarballs of a particular version would lack the copyright
attribution, but in that case, my solution would be to generate it from
the commit history at packaging time.
The example in t/README has has a copyright notice which is why I put
one in but I don't consider the test (or the fix itself) to actually be
copyrightable. If I wasn't creating a new file I wouldn't have bothered
putting anything in (other than the testcase).
From: Jeff King <hidden> Date: 2016-06-15 22:52:04
On Tue, Sep 20, 2011 at 09:04:46PM +1200, Chris Packham wrote:
quoted
Although other projects do use "cc" in the commit message, I think we
don't usually bother adding this noise in the git project. The cc
headers in your email are enough.
That's more for git send-email's benefit than anything else. I'm working
on a laptop with a touchpad (and a cat) so the less switching between
editor and MUA the better. Any better suggestions for tracking Cc's for
git send-email?
It would depend on your workflow, I think. You can use --cc to add
headers to format-patch. You could get very fancy and store them in
git-notes or somewhere else, and then pull them in with send-email's
cc-cmd option. But I suspect you just want to stick them in the commit
message one time and then have it used each time.
If put them after the double-dash line in your commit message, like:
subject
body
---
cc: whoever
Then that will be included verbatim in the mail by format-patch,
send-email will respect the cc line, and those lines will be dropped by
"git am" when Junio applies the patch (they are still a slight noise to
readers of the mail, but at least they don't make it into the commit
history).
The example in t/README has has a copyright notice which is why I put
one in but I don't consider the test (or the fix itself) to actually be
copyrightable. If I wasn't creating a new file I wouldn't have bothered
putting anything in (other than the testcase).
Yeah, that's why I said I don't know if we have a policy. We clearly
have a lot of copyright statements, but they are all horribly out of
date. I was hoping Junio might weigh in.
-Peff
From: Jeff Epler <hidden> Date: 2016-06-15 22:52:05
On Sun, Sep 18, 2011 at 11:50:30AM -0700, Jakub Narebski wrote:
Perhaps more descriptive name, i.e.
linkify.<name>.regexp
linkify.<name>.subst
would be better?
I guess that regexp is an extended regular expression, isn't it?
If "regexp" is clearer than "re" then I have no quarrel with changing
it. The typical user won't be typing these over and over, so the value
of brevity is limited.
As written, it's whatever is accepted by tcl's regular expression
matcher, which is described in re_syntax(n), installed as
re_syntax(3tcl) on debian-derived systems. A one-sentence summary of a
TCL "ARE" is "basically EREs with some significant extensions".
It is probably possible to write expressions that are going to work the
same in tcl, perl, and posix regular expressions, but to some extent the
user who writes a complex expression and then tries to use it with both
gitk and a future gitweb will simply be permitted to keep both pieces
when it breaks.
Is it unnecessarily complicated to design
linkify.<name>.(regexp|subst)
*AND*
gitk.linkify.<name>.(regexp|subst)
in from the start? This way the hypothetical power user can write a
different version of the expression for gitk and future gitweb if it is
required by RE dialect differences.
Jeff
From: Jeff Epler <hidden> Date: 2016-06-15 22:52:05
Many projects use project-specific notations in changelogs to refer
to bug trackers and the like. One example is the "Closes: #12345"
notation used in Debian.
Make gitk configurable so that arbitrary strings can be turned into
clickable links that are opened in a web browser.
Signed-off-by: Jeff Epler <redacted>
---
Since the previous patch, I
* Renamed configuration variables to get rid of the "gitk" prefix
to encourage other git-related programs to adopt the same
functionality.
* Renamed configuration variables from cryptic ".re", ".sub" to less
cryptic ".regexp" and "subst"
* Changed the example RE to be an ERE (no \d or \M)
* Documented that these are POSIX EREs; hopefully that's OK. I see
in CodingGuidelines that in git itself "a subset of BREs" are used,
so maybe even this is too much power. And hopefully tcl's
re_syntax really is close enough to an ERE superset that this isn't
a terrible lie about the initial implementation either.
* Added a Signed-Off-By, since I've had a number of positive feedbacks
and the only problems I've heard of (since patch v2) are the ones
related to 'eval' in git-web--browse.
In v2 of the patch, I had fixed a problem with %-signs in URLs and
changed the documentation example.
Documentation/config.txt | 30 +++++++++++++++++-
gitk-git/gitk | 75 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 102 insertions(+), 3 deletions(-)
@@ -1064,6 +1064,10 @@ All gitcvs variables except for 'gitcvs.usecrlfattr' and is one of "ext" and "pserver") to make them apply only for the given access method.+gitk.browser::+ Specify the browser that will be used to open links generated by+ 'linkify' configuration options.+ grep.lineNumber:: If set to true, enable '-n' option by default.
@@ -1317,6 +1321,28 @@ interactive.singlekey:: setting is silently ignored if portable keystroke input is not available.+linkify.<name>.regexp::+ Specify a regular expression in the POSIX Extended Regular Expression+ syntax defining a class of strings to automatically convert to+ hyperlinks. This regular expression many not span multiple lines.+ You must also specify 'linkify.<name>.subst'.++linkify.<name>.subst::+ Specify a substitution that results in the target URL for the+ related regular expression. Back-references like '\1' refer+ to capturing groups in the associated regular expression.+ You must also specify 'linkify.<name>.regexp'.+++For example, to automatically link from Debian-style "Closes: #nnnn"+message to the Debian BTS,+++--------+ git config linkify.debian-bts.regexp '#([1-9][0-9]*)'+ git config linkify.debian-bts.subst 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1'+--------+++Currently, only linkgit:gitk[1] converts strings to links in this fashion.+ log.abbrevCommit:: If true, makes linkgit:git-log[1], linkgit:git-show[1], and linkgit:git-whatchanged[1] assume `\--abbrev-commit`. You may
@@ -1870,5 +1896,5 @@ user.signingkey:: web.browser:: Specify a web browser that may be used by some commands.- Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]- may use it.+ Currently only linkgit:git-instaweb[1], linkgit:gitk[1],+ and linkgit:git-help[1] may use it.
@@ -6684,7 +6684,7 @@ proc commit_descriptor {p} { # append some text to the ctext widget, and make any SHA1 ID # that we know about be a clickable link. proc appendwithlinks {text tags} {- global ctext linknum curview+ global ctext linknum curview linkmakers set start [$ctext index "end - 1c"] $ctext insert end $text $tags
@@ -6699,6 +6699,30 @@ proc appendwithlinks {text tags} { setlink $linkid link$linknum incr linknum }++ if {$linkmakers == {}} return++ set link_re {}+ foreach {re rep} $linkmakers { lappend link_re $re }+ set link_re "([join $link_re {)|(}])"++ set ee 0+ while {[regexp -indices -start $ee -- $link_re $text l]} {+ set s [lindex $l 0]+ set e [lindex $l 1]+ set linktext [string range $text $s $e]+ incr e+ set ee $e++ foreach {re rep} $linkmakers {+ if {![regsub $re $linktext $rep linkurl]} continue+ $ctext tag delete link$linknum+ $ctext tag add link$linknum "$start + $s c" "$start + $e c"+ seturllink $linkurl link$linknum+ incr linknum+ break+ }+ } } proc setlink {id lk} {
@@ -6726,6 +6750,53 @@ proc setlink {id lk} { } }+proc get_link_config {} {+ if {[catch {exec git config -z --get-regexp {^linkify\.}} linkers]} {+ return {}+ }++ set linktypes [list]+ foreach item [split $linkers "\0"] {+ if {$item == ""} continue+ if {![regexp {linkify\.(\S+)\.(regexp|subst)\s(.*)} $item _ k t v]} {+ continue+ }+ set linkconfig($t,$k) $v+ if {$t == "regexp"} { lappend linktypes $k }+ }++ set linkmakers [list]+ foreach k $linktypes {+ if {![info exists linkconfig(subst,$k)]} {+ puts stderr "Warning: link `$k' is missing a substitution string"+ } elseif {[catch {regexp -inline -- $linkconfig(regexp,$k) ""} err]} {+ puts stderr "Warning: link `$k': $err"+ } else {+ lappend linkmakers $linkconfig(regexp,$k) $linkconfig(subst,$k)+ }+ unset linkconfig(regexp,$k)+ unset -nocomplain linkconfig(subst,$k)+ }+ foreach k [array names linkconfig] {+ regexp "subst,(.*)" $k _ k+ puts stderr "Warning: link `$k' is missing a regular expression"+ }+ set linkmakers+}++proc openlink {url} {+ exec git web--browse --config=gitk.browser $url &+}++proc seturllink {url lk} {+ set qurl [string map {% %%} $url]+ global ctext+ $ctext tag conf $lk -foreground blue -underline 1+ $ctext tag bind $lk <1> [list openlink $qurl]+ $ctext tag bind $lk <Enter> {linkcursor %W 1}+ $ctext tag bind $lk <Leave> {linkcursor %W -1}+}+ proc appendshortlink {id {pre {}} {post {}}} { global ctext linknum
From: Jeff Epler <hidden> Date: 2016-06-15 22:52:13
Many projects use project-specific notations in changelogs to refer
to bug trackers and the like. One example is the "Closes: #12345"
notation used in Debian.
Make gitk configurable so that arbitrary strings can be turned into
clickable links that are opened in a web browser.
Signed-off-by: Jeff Epler <redacted>
---
This v3 patch didn't generate any discussion last time around (~3 weeks
ago), so I've taken the liberty of reposting it.
I'm aware of no problems with this patch, and a number of people have
commented that it is useful to them. For URLs that contain "&" and
other shell metacharacters, it *does* depend on r480f062c
"git-web--browse: avoid the use of eval" which is in next but not maint.
Since the V2 patch, I
* Renamed configuration variables to get rid of the "gitk" prefix
to encourage other git-related programs to adopt the same
functionality.
* Renamed configuration variables from cryptic "re", "sub" to less
cryptic "regexp" and "subst"
* Changed the example RE to be an ERE (no \d or \M)
* Documented that these are POSIX EREs; hopefully that's OK. I see
in CodingGuidelines that in git itself "a subset of BREs" are used,
so maybe even this is too much power. And hopefully tcl's
re_syntax really is close enough to an ERE superset that this isn't
a terrible lie about the initial implementation either.
* Added a Signed-Off-By, since I've had a number of positive feedbacks
and the only problems I've heard of (since patch v2) are the ones
related to 'eval' in git-web--browse.
In v2 of the patch, I had fixed a problem with %-signs in URLs and
changed the documentation example.
Documentation/config.txt | 30 +++++++++++++++++-
gitk-git/gitk | 75 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 102 insertions(+), 3 deletions(-)
@@ -1064,6 +1064,10 @@ All gitcvs variables except for 'gitcvs.usecrlfattr' and is one of "ext" and "pserver") to make them apply only for the given access method.+gitk.browser::+ Specify the browser that will be used to open links generated by+ 'linkify' configuration options.+ grep.lineNumber:: If set to true, enable '-n' option by default.
@@ -1317,6 +1321,28 @@ interactive.singlekey:: setting is silently ignored if portable keystroke input is not available.+linkify.<name>.regexp::+ Specify a regular expression in the POSIX Extended Regular Expression+ syntax defining a class of strings to automatically convert to+ hyperlinks. This regular expression many not span multiple lines.+ You must also specify 'linkify.<name>.subst'.++linkify.<name>.subst::+ Specify a substitution that results in the target URL for the+ related regular expression. Back-references like '\1' refer+ to capturing groups in the associated regular expression.+ You must also specify 'linkify.<name>.regexp'.+++For example, to automatically link from Debian-style "Closes: #nnnn"+message to the Debian BTS,+++--------+ git config linkify.debian-bts.regexp '#([1-9][0-9]*)'+ git config linkify.debian-bts.subst 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\1'+--------+++Currently, only linkgit:gitk[1] converts strings to links in this fashion.+ log.abbrevCommit:: If true, makes linkgit:git-log[1], linkgit:git-show[1], and linkgit:git-whatchanged[1] assume `\--abbrev-commit`. You may
@@ -1870,5 +1896,5 @@ user.signingkey:: web.browser:: Specify a web browser that may be used by some commands.- Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]- may use it.+ Currently only linkgit:git-instaweb[1], linkgit:gitk[1],+ and linkgit:git-help[1] may use it.
@@ -6684,7 +6684,7 @@ proc commit_descriptor {p} { # append some text to the ctext widget, and make any SHA1 ID # that we know about be a clickable link. proc appendwithlinks {text tags} {- global ctext linknum curview+ global ctext linknum curview linkmakers set start [$ctext index "end - 1c"] $ctext insert end $text $tags
@@ -6699,6 +6699,30 @@ proc appendwithlinks {text tags} { setlink $linkid link$linknum incr linknum }++ if {$linkmakers == {}} return++ set link_re {}+ foreach {re rep} $linkmakers { lappend link_re $re }+ set link_re "([join $link_re {)|(}])"++ set ee 0+ while {[regexp -indices -start $ee -- $link_re $text l]} {+ set s [lindex $l 0]+ set e [lindex $l 1]+ set linktext [string range $text $s $e]+ incr e+ set ee $e++ foreach {re rep} $linkmakers {+ if {![regsub $re $linktext $rep linkurl]} continue+ $ctext tag delete link$linknum+ $ctext tag add link$linknum "$start + $s c" "$start + $e c"+ seturllink $linkurl link$linknum+ incr linknum+ break+ }+ } } proc setlink {id lk} {
@@ -6726,6 +6750,53 @@ proc setlink {id lk} { } }+proc get_link_config {} {+ if {[catch {exec git config -z --get-regexp {^linkify\.}} linkers]} {+ return {}+ }++ set linktypes [list]+ foreach item [split $linkers "\0"] {+ if {$item == ""} continue+ if {![regexp {linkify\.(\S+)\.(regexp|subst)\s(.*)} $item _ k t v]} {+ continue+ }+ set linkconfig($t,$k) $v+ if {$t == "regexp"} { lappend linktypes $k }+ }++ set linkmakers [list]+ foreach k $linktypes {+ if {![info exists linkconfig(subst,$k)]} {+ puts stderr "Warning: link `$k' is missing a substitution string"+ } elseif {[catch {regexp -inline -- $linkconfig(regexp,$k) ""} err]} {+ puts stderr "Warning: link `$k': $err"+ } else {+ lappend linkmakers $linkconfig(regexp,$k) $linkconfig(subst,$k)+ }+ unset linkconfig(regexp,$k)+ unset -nocomplain linkconfig(subst,$k)+ }+ foreach k [array names linkconfig] {+ regexp "subst,(.*)" $k _ k+ puts stderr "Warning: link `$k' is missing a regular expression"+ }+ set linkmakers+}++proc openlink {url} {+ exec git web--browse --config=gitk.browser $url &+}++proc seturllink {url lk} {+ set qurl [string map {% %%} $url]+ global ctext+ $ctext tag conf $lk -foreground blue -underline 1+ $ctext tag bind $lk <1> [list openlink $qurl]+ $ctext tag bind $lk <Enter> {linkcursor %W 1}+ $ctext tag bind $lk <Leave> {linkcursor %W -1}+}+ proc appendshortlink {id {pre {}} {post {}}} { global ctext linknum