[GIT PULL] gitk update

[Paul Mackerras]

Hi Junio,

Whenever it's convenient, please do a pull from my gitk repository at
git://ozlabs.org/~paulus/gitk.git to get four commits updating gitk.

Thanks,
Paul.


Gabriele Mazzotta (1):
  gitk: Do not mistake unchanged lines for submodule changes

Paul Mackerras (1):
  gitk: Make web links clickable

Paul Wise (1):
  gitk: Use right colour for remote refs in the "Tags and heads" dialog

YanKe (1):
  gitk: Add Chinese (zh_CN) translation

 gitk|   64 ++-
 po/zh_CN.po | 1367 +++
 2 files changed, 1427 insertions(+), 4 deletions(-)
 create mode 100644 po/zh_CN.po

Re: [PATCH] gitk: Do not mistake unchanged lines with submodule changes

[Paul Mackerras]

On Sat, Mar 23, 2019 at 06:00:36PM +0100, Gabriele Mazzotta wrote:
> Unchanged lines are prefixed with a white-space, thus unchanged lines
> starting with either " <" or " >" are mistaken for submodule changes.
> Check if a line starts with either "  <" or "  >" only if we listing
> the changes of a submodule.
> 
> Signed-off-by: Gabriele Mazzotta 

Thanks, patch applied to my git://ozlabs.org/~paulus/gitk.git repository.

Paul.

Re: [PATCH v2] gitk: Make web links clickable

[Paul Mackerras]

On Fri, Aug 30, 2019 at 12:02:07AM +0530, Pratyush Yadav wrote:
> On 29/08/19 11:27AM, Paul Mackerras wrote:
> > This makes gitk look for http or https URLs in the commit description
> > and make the URLs clickable.  Clicking on them will invoke an external
> > web browser with the URL.
> > 
> > The web browser command is by default "xdg-open" on Linux, "open" on
> > MacOS, and "cmd /c start" on Windows.  The command can be changed in
> > the preferences window, and it can include parameters as well as the
> > command name.  If it is set to the empty string then URLs will no
> > longer be made clickable.
> > 
> > Signed-off-by: Paul Mackerras 
> > ---
> > v2: Match URLs anywhere, not just after [Bug]Link:.
> > 
> >  gitk | 51 ++-
> >  1 file changed, 50 insertions(+), 1 deletion(-)
> > 
> > diff --git a/gitk b/gitk
> > index a14d7a1..2a0d00c 100755
> > --- a/gitk
> > +++ b/gitk
> > @@ -7016,6 +7016,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.
> > +# Also look for URLs of the form "http[s]://..." and make them web links.
> >  proc appendwithlinks {text tags} {
> >  global ctext linknum curview
> >  
> > @@ -7032,6 +7033,18 @@ proc appendwithlinks {text tags} {
> > setlink $linkid link$linknum
> > incr linknum
> >  }
> > +set wlinks [regexp -indices -all -inline -line \
> > +   {https?://[^[:space:]]+} $text]
> 
> I know I suggested searching till the first non-whitespace character, 
> but thinking more about, there are some problematic cases. Say someone 
> has a commit message like:
>   
>   Foo bar baz (more details at https://example.com/hello)
> 
> Or like:
> 
>   Check out https://foo.com, https://bar.com
> 
> In the first example, the closing parenthesis gets included in the link, 
> but shouldn't be. In the second, the comma after foo.com would be 
> included in the link, but shouldn't be. So maybe use a more 
> sophisticated regex?

I did think about that, but it seems to be impossible to get it right
in all cases, so I went for simple and obvious.  In particular I don't
see how to handle the common case of a '.' immediately following the
URL, since '.' is a legal character in a URL.

> A quick Google search gives out the following options [0][1].
> 
> [0] gives the following regex:
> 
>   
> https?:\/\/(www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)
> 
> It is kind of ugly to look at, and I'm not even sure if there are any 
> syntax differences with Tcl's regex library.
> 
> [1] lists a bunch of regexes and which URLs they work on and which ones 
> they don't. The smallest among them I found is:
> 
>   @^(https?|ftp)://[^\s/$.?#].[^\s]*$@iS
> 
> Again, I'm not sure how well this would work with Tcl's regex library, 
> or how commonly these URL patterns appear in actual commit messages.  
> Just something to consider.
> 
> [0] 
> https://stackoverflow.com/questions/3809401/what-is-a-good-regular-expression-to-match-a-url
> [1] https://mathiasbynens.be/demo/url-regex

I think I would be inclined to make the regex customizable, since that
would also allow the user to match ftp or other URLs if they want.
The only difficulty with that is if there are subexpressions, that
will change how we have to interpret the list returned by the
regexp -indices -all -inline command.

Paul.

[PATCH v2] gitk: Make web links clickable

[Paul Mackerras]

This makes gitk look for http or https URLs in the commit description
and make the URLs clickable.  Clicking on them will invoke an external
web browser with the URL.

The web browser command is by default "xdg-open" on Linux, "open" on
MacOS, and "cmd /c start" on Windows.  The command can be changed in
the preferences window, and it can include parameters as well as the
command name.  If it is set to the empty string then URLs will no
longer be made clickable.

Signed-off-by: Paul Mackerras 
---
v2: Match URLs anywhere, not just after [Bug]Link:.

 gitk | 51 ++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/gitk b/gitk
index a14d7a1..2a0d00c 100755
--- a/gitk
+++ b/gitk
@@ -7016,6 +7016,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.
+# Also look for URLs of the form "http[s]://..." and make them web links.
 proc appendwithlinks {text tags} {
 global ctext linknum curview
 
@@ -7032,6 +7033,18 @@ proc appendwithlinks {text tags} {
setlink $linkid link$linknum
incr linknum
 }
+set wlinks [regexp -indices -all -inline -line \
+   {https?://[^[:space:]]+} $text]
+foreach l $wlinks {
+   set s2 [lindex $l 0]
+   set e2 [lindex $l 1]
+   set url [string range $text $s2 $e2]
+   incr e2
+   $ctext tag delete link$linknum
+   $ctext tag add link$linknum "$start + $s2 c" "$start + $e2 c"
+   setwlink $url link$linknum
+   incr linknum
+}
 }
 
 proc setlink {id lk} {
@@ -7064,6 +7077,18 @@ proc setlink {id lk} {
 }
 }
 
+proc setwlink {url lk} {
+global ctext
+global linkfgcolor
+global web_browser
+
+if {$web_browser eq {}} return
+$ctext tag conf $lk -foreground $linkfgcolor -underline 1
+$ctext tag bind $lk <1> [list browseweb $url]
+$ctext tag bind $lk  {linkcursor %W 1}
+$ctext tag bind $lk  {linkcursor %W -1}
+}
+
 proc appendshortlink {id {pre {}} {post {}}} {
 global ctext linknum
 
@@ -7098,6 +7123,16 @@ proc linkcursor {w inc} {
 }
 }
 
+proc browseweb {url} {
+global web_browser
+
+if {$web_browser eq {}} return
+# Use eval here in case $web_browser is a command plus some arguments
+if {[catch {eval exec $web_browser [list $url] &} err]} {
+   error_popup "[mc "Error starting web browser:"] $err"
+}
+}
+
 proc viewnextline {dir} {
 global canv linespc
 
@@ -11488,7 +11523,7 @@ proc create_prefs_page {w} {
 proc prefspage_general {notebook} {
 global NS maxwidth maxgraphpct showneartags showlocalchanges
 global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
-global hideremotes want_ttk have_ttk maxrefs
+global hideremotes want_ttk have_ttk maxrefs web_browser
 
 set page [create_prefs_page $notebook.general]
 
@@ -11539,6 +11574,13 @@ proc prefspage_general {notebook} {
 pack configure $page.extdifff.l -padx 10
 grid x $page.extdifff $page.extdifft -sticky ew
 
+${NS}::entry $page.webbrowser -textvariable web_browser
+${NS}::frame $page.webbrowserf
+${NS}::label $page.webbrowserf.l -text [mc "Web browser" ]
+pack $page.webbrowserf.l -side left
+pack configure $page.webbrowserf.l -padx 10
+grid x $page.webbrowserf $page.webbrowser -sticky ew
+
 ${NS}::label $page.lgen -text [mc "General options"]
 grid $page.lgen - -sticky w -pady 10
 ${NS}::checkbutton $page.want_ttk -variable want_ttk \
@@ -12310,6 +12352,7 @@ if {[tk windowingsystem] eq "win32"} {
 set bgcolor SystemWindow
 set fgcolor SystemWindowText
 set selectbgcolor SystemHighlight
+set web_browser "cmd /c start"
 } else {
 set uicolor grey85
 set uifgcolor black
@@ -12317,6 +12360,11 @@ if {[tk windowingsystem] eq "win32"} {
 set bgcolor white
 set fgcolor black
 set selectbgcolor gray85
+if {[tk windowingsystem] eq "aqua"} {
+   set web_browser "open"
+} else {
+   set web_browser "xdg-open"
+}
 }
 set diffcolors {red "#00a000" blue}
 set diffcontext 3
@@ -12390,6 +12438,7 @@ set config_variables {
 filesepbgcolor filesepfgcolor linehoverbgcolor linehoverfgcolor
 linehoveroutlinecolor mainheadcirclecolor workingfilescirclecolor
 indexcirclecolor circlecolors linkfgcolor circleoutlinecolor
+web_browser
 }
 foreach var $config_variables {
 config_init_trace $var
-- 
2.7.4

Re: [PATCH] gitk: Make web links clickable

[Paul Mackerras]

Hi Junio,

On Tue, Aug 27, 2019 at 01:32:30PM -0700, Junio C Hamano wrote:
> Paul Mackerras  writes:
> 
> > This makes gitk look for lines in the commit message which start with
> > "Link:" or "BugLink:" followed by a http or https URL, and make the
> > URL clickable.  Clicking on it will invoke an external web browser with
> > the URL.
> >
> > The web browser command is by default "xdg-open" on Linux, "open" on
> > MacOS, and "cmd /c start" on Windows.  The command can be changed in
> > the preferences window, and it can include parameters as well as the
> > command name.  If it is set to the empty string then URLs will no
> > longer be made clickable.
> >
> > Signed-off-by: Paul Mackerras 
> > ---
> 
> >  gitk | 51 ++-
> >  1 file changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/gitk b/gitk
> > index a14d7a1..4577150 100755
> > --- a/gitk
> > +++ b/gitk
> > @@ -7016,6 +7016,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.
> > +# Also look for lines of the form "Link: http..." and make them web links.
> 
> FWIW, I personally hate those "Link:" that do not say what the links
> are for (IOW, I am OK with "BugLink:" or even "Bug:").
> 
> In any case, I polled your repository but I did not find anything to
> pull.  Do you want me to start my own gitk mirror, queue this patch
> there and pull from it myself, or is this meant to be a preview of
> what you'll tell me to pull in a few days?

I was expecting some comments and suggestions, so I didn't push it out
yet.  One suggestion which seems reasonable is to match any http or
https URL anywhere in the commit description, not just with Link: or
BugLink: at the start of the line.  What do you think of that?  It's
quite easy to do.  Also it should stop at whitespace rather than going
to the end of the line.

Paul.

[PATCH] gitk: Make web links clickable

[Paul Mackerras]

This makes gitk look for lines in the commit message which start with
"Link:" or "BugLink:" followed by a http or https URL, and make the
URL clickable.  Clicking on it will invoke an external web browser with
the URL.

The web browser command is by default "xdg-open" on Linux, "open" on
MacOS, and "cmd /c start" on Windows.  The command can be changed in
the preferences window, and it can include parameters as well as the
command name.  If it is set to the empty string then URLs will no
longer be made clickable.

Signed-off-by: Paul Mackerras 
---
 gitk | 51 ++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/gitk b/gitk
index a14d7a1..4577150 100755
--- a/gitk
+++ b/gitk
@@ -7016,6 +7016,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.
+# Also look for lines of the form "Link: http..." and make them web links.
 proc appendwithlinks {text tags} {
 global ctext linknum curview
 
@@ -7032,6 +7033,18 @@ proc appendwithlinks {text tags} {
setlink $linkid link$linknum
incr linknum
 }
+set wlinks [regexp -indices -all -inline -line \
+   {^ *(Bug|)Link: (https?://.*)$} $text]
+foreach {l sub1 sub2} $wlinks {
+   set s2 [lindex $sub2 0]
+   set e2 [lindex $sub2 1]
+   set url [string range $text $s2 $e2]
+   incr e2
+   $ctext tag delete link$linknum
+   $ctext tag add link$linknum "$start + $s2 c" "$start + $e2 c"
+   setwlink $url link$linknum
+   incr linknum
+}
 }
 
 proc setlink {id lk} {
@@ -7064,6 +7077,18 @@ proc setlink {id lk} {
 }
 }
 
+proc setwlink {url lk} {
+global ctext
+global linkfgcolor
+global web_browser
+
+if {$web_browser eq {}} return
+$ctext tag conf $lk -foreground $linkfgcolor -underline 1
+$ctext tag bind $lk <1> [list browseweb $url]
+$ctext tag bind $lk  {linkcursor %W 1}
+$ctext tag bind $lk  {linkcursor %W -1}
+}
+
 proc appendshortlink {id {pre {}} {post {}}} {
 global ctext linknum
 
@@ -7098,6 +7123,16 @@ proc linkcursor {w inc} {
 }
 }
 
+proc browseweb {url} {
+global web_browser
+
+if {$web_browser eq {}} return
+# Use eval here in case $web_browser is a command plus some arguments
+if {[catch {eval exec $web_browser [list $url] &} err]} {
+   error_popup "[mc "Error starting web browser:"] $err"
+}
+}
+
 proc viewnextline {dir} {
 global canv linespc
 
@@ -11488,7 +11523,7 @@ proc create_prefs_page {w} {
 proc prefspage_general {notebook} {
 global NS maxwidth maxgraphpct showneartags showlocalchanges
 global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
-global hideremotes want_ttk have_ttk maxrefs
+global hideremotes want_ttk have_ttk maxrefs web_browser
 
 set page [create_prefs_page $notebook.general]
 
@@ -11539,6 +11574,13 @@ proc prefspage_general {notebook} {
 pack configure $page.extdifff.l -padx 10
 grid x $page.extdifff $page.extdifft -sticky ew
 
+${NS}::entry $page.webbrowser -textvariable web_browser
+${NS}::frame $page.webbrowserf
+${NS}::label $page.webbrowserf.l -text [mc "Web browser" ]
+pack $page.webbrowserf.l -side left
+pack configure $page.webbrowserf.l -padx 10
+grid x $page.webbrowserf $page.webbrowser -sticky ew
+
 ${NS}::label $page.lgen -text [mc "General options"]
 grid $page.lgen - -sticky w -pady 10
 ${NS}::checkbutton $page.want_ttk -variable want_ttk \
@@ -12310,6 +12352,7 @@ if {[tk windowingsystem] eq "win32"} {
 set bgcolor SystemWindow
 set fgcolor SystemWindowText
 set selectbgcolor SystemHighlight
+set web_browser "cmd /c start"
 } else {
 set uicolor grey85
 set uifgcolor black
@@ -12317,6 +12360,11 @@ if {[tk windowingsystem] eq "win32"} {
 set bgcolor white
 set fgcolor black
 set selectbgcolor gray85
+if {[tk windowingsystem] eq "aqua"} {
+   set web_browser "open"
+} else {
+   set web_browser "xdg-open"
+}
 }
 set diffcolors {red "#00a000" blue}
 set diffcontext 3
@@ -12390,6 +12438,7 @@ set config_variables {
 filesepbgcolor filesepfgcolor linehoverbgcolor linehoverfgcolor
 linehoveroutlinecolor mainheadcirclecolor workingfilescirclecolor
 indexcirclecolor circlecolors linkfgcolor circleoutlinecolor
+web_browser
 }
 foreach var $config_variables {
 config_init_trace $var
-- 
2.7.4

Re: [PATCH 1/1] gitk: Update Bulgarian translation (317t)

[Paul Mackerras]

On Wed, Mar 13, 2019 at 01:28:33PM +0100, Alexander Shopov wrote:
> Signed-off-by: Alexander Shopov 

Thanks, applied.

Paul.

Re: Update of Bulgarian translation of gitk

[Paul Mackerras]

On Wed, Mar 13, 2019 at 01:06:32PM +0100, Alexander Shopov wrote:
> 
> 
> Hello all,
> I am resending the update of Bulgarina translation of Gitk that I last sent 
> here:
> on 4 of March: https://marc.info/?l=git&m=155169580131311&w=2
> Any idea why it is not getting merged? Perhaps I missed something or Paul 
> Mackerras,
> maintaining gitk, is busy?

I have been busy with work and life generally.  I applied your patch
and pushed it out.  Thanks for your patience.

Paul.

Re: [PATCH 1/2] gitk: refresh the colour scheme

[Paul Mackerras]

On Tue, Feb 26, 2019 at 12:05:34PM +0100, Andrej Shadura wrote:
> The colours gitk is currently using are from the basic 16 colour
> palette, and are a bit too intensive to be comfortable or pleasant
> to work with.
> 
> Adjust the main colours (commit nodes, remotes, tags and one branch
> colour) to be slightly softer.
> 
> Signed-off-by: Andrej Shadura 

Thanks for the patch, but I disagree.  I do like the change you made
to the tag colours, but the blue you have for the commit node circles
is pretty blah.  That needs a more definite colour.

Also, the "too intensive to be comfortable or pleasant" in the commit
message reflect a personal preference, and the way it is put seems to
me to be too intensive to be comfortable or pleasant.

Paul.

Re: [PATCH] gitk: remove translated message from comments

[Paul Mackerras]

On Tue, Jan 17, 2017 at 07:52:45PM -0800, David Aguilar wrote:
> "make update-po" fails because a previously untranslated string
> has now been translated:
> 
>   Updating po/sv.po
>   po/sv.po:1388: duplicate message definition...
>   po/sv.po:380: ...this is the location of the first definition
> 
> Remove the duplicate message definition.
> 
> Reported-by: Junio C Hamano 
> Signed-off-by: David Aguilar 

Thanks, applied.

Junio, please do a pull from my repository to get this fix.
The new head is 7f03c6e32891.

Paul.

Re: gitk pull request // was: Re: gitk: "lime" color incompatible with older Tk versions

[Paul Mackerras]

Hi Junio,

On Sat, Jan 14, 2017 at 06:35:43PM -0800, Junio C Hamano wrote:
> David Aguilar  writes:
> 
> > On Fri, Jan 13, 2017 at 03:20:43AM -0800, David Aguilar wrote:
> >> 
> >> Ping.. it would be nice to get this patch applied.
> >
> > Sorry for the noise, and thank you Paul for the fix.
> > This was already fixed by Paul in gitk@22a713c72df.
> >
> > I'm sure Junio will merge gitk.git into git.git soon enough so I
> > can sit tight until then, but while I'm here I might as well
> > send out a pull request:
> >
> > The following changes since commit 22a713c72df8b6799c59287c50cee44c4a6db51e:
> >
> >   gitk: Follow themed bgcolor in help dialogs (2016-03-19 14:12:21 +1100)
> >
> > are available in the git repository at:
> >
> >   git://ozlabs.org/~paulus/gitk.git 
> >
> > for you to fetch changes up to fbf426478e540f4737860dae622603cc0daba3d2:
> >
> >   gitk: Update copyright notice to 2016 (2016-12-12 20:46:42 +1100)
> 
> Pinging Paul to signal me that his tree is ready to pull from is
> appreciated, and asking Paul if his tree is ready to be pulled and
> then relaying his answer to me is also fine, but I am sensing that
> this message is neither.  So let me double check.
> 
> Paul, is it a good time to pull, or do you still have something not
> published yet that should go together with what you have already
> queued?

I recently pushed out one more commit to update the Russian
translation from Dimitriy Ryazantcev.  The head is now 8fef3f36b779.
I have a couple more series that I am currently reviewing, but nothing
immediately ready to publish.  It would be a good time for you to do a
pull, since the "lime" color fix and the memory consumption fixes
should be helpful for a lot of people.

Thanks,
Paul.

Re: [PATCH 2/6] Add ability to follow a remote branch with a dialog

[Paul Mackerras]

On Thu, Dec 15, 2016 at 09:58:43PM +1030, Pierre Dumuid wrote:
> A suggested name is provided when creating a new "following" branch.
> 
> Signed-off-by: Pierre Dumuid 
> ---
>  gitk | 86 
> 
>  1 file changed, 82 insertions(+), 4 deletions(-)
> 
> diff --git a/gitk b/gitk
> index 50d1ef4..36cba49 100755
> --- a/gitk
> +++ b/gitk
> @@ -2673,6 +2673,7 @@ proc makewindow {} {
>   {mc "Rename this branch" command mvbranch}
>   {mc "Remove this branch" command rmbranch}
>   {mc "Copy branch name" command {clipboard clear; clipboard append 
> $headmenuhead}}
> + {mc "Follow this branch"  command follow_remote_branch_dialog}
>  }
>  $headctxmenu configure -tearoff 0
>  
> @@ -9947,23 +9948,100 @@ proc headmenu {x y id head} {
>  stopfinding
>  set headmenuid $id
>  set headmenuhead $head
> -array set state {0 normal 1 normal 2 normal}
> +array set state {0 normal 1 normal 2 normal 3 normal}
>  if {[string match "remotes/*" $head]} {
>   set localhead [string range $head [expr [string last / $head] + 1] end]
>   if {[info exists headids($localhead)]} {
>   set state(0) disabled
>   }
> - array set state {1 disabled 2 disabled}
> + array set state {1 disabled 2 disabled 3 normal}

You set array(3) to "normal" just above, no need to do it again.

>  }
>  if {$head eq $mainhead} {
> - array set state {0 disabled 2 disabled}
> + array set state {0 disabled 2 disabled 3 disabled}
> +} else {
> + set state(3) disabled
>  }

As far as I can see, this will always end up with state(3) set to
"disabled", won't it?  Is that really what you want?

Paul.

Re: [PATCH 1/6] Enable ability to visualise the results of git cherry C1 C2

[Paul Mackerras]

On Thu, Dec 15, 2016 at 09:58:42PM +1030, Pierre Dumuid wrote:
> It's a bit clunky but it works!!
> 
> Usage:
>  - mark commit one (e.g. v45)
>  - Select commit two.
>  - Switch the gdttype to the option, "git-cherry between marked commit and:"

This needs a better description.  "Git-cherry between marked commit
and" is a description of an implementation not a description of what's
being achieved.  Having read the git cherry man page, it seems like
it's (Find commit) included in marked commit but not in this commit
(or the other way around?).  We would need a terser description that
that, though.

[...]

> +proc update_gitcherrylist {} {
> +global gitcherryids
> +global markedid
> +global findstring
> +global fstring
> +global currentid
> +global iddrawn
> +
> +unset -nocomplain gitcherryids
> +set fs $findstring
> +
> +if {$findstring eq {}} {
> + $fstring delete 0 end
> + $fstring insert 0 $currentid
> +}
> +
> +if {![info exists markedid]} {
> + error_popup [mc "Please mark a git commit before using this find 
> method!"]
> + return
> +}
> +
> +#puts [join [list "Running cherry between: `" $markedid "` and `" 
> $findstring "`"] ""]
> +
> +if {[catch {set cherryOutput [exec git cherry $markedid $findstring]}]} {

How long could the git cherry take to run?  If it's more than a
fraction of a second, then we would need to handle its output
asynchronously like we do in [do_file_hl].

Paul.

Re: [PATCH 3/6] Add a tree view to the local branches, remote branches and tags, where / is treated as a directory seperator.

[Paul Mackerras]

On Thu, Dec 15, 2016 at 09:58:44PM +1030, Pierre Dumuid wrote:
> Signed-off-by: Pierre Dumuid 
> ---
>  gitk | 117 
> +++
>  1 file changed, 117 insertions(+)

Nice idea in general... a few comments below.  Also, please don't put
the entire commit message in the subject line. :)

> diff --git a/gitk b/gitk
> index 36cba49..a894f1d 100755
> --- a/gitk
> +++ b/gitk
> @@ -2089,6 +2089,10 @@ proc makewindow {} {
>   {mc "Reread re&ferences" command rereadrefs}
>   {mc "&List references" command showrefs -accelerator F2}
>   {xx "" separator}
> + {mc "List Local Branches"  command {show_tree_of_references_dialog 
> "localBranches"}  -accelerator F6}
> + {mc "List Remote Branches" command {show_tree_of_references_dialog 
> "remoteBranches"} -accelerator F7}
> + {mc "List Tags"command {show_tree_of_references_dialog 
> "tags"}   -accelerator F8}
> + {xx "" separator}
>   {mc "Start git &gui" command {exec git gui &}}
>   {xx "" separator}
>   {mc "&Quit" command doquit -accelerator Meta1-Q}
> @@ -2601,6 +2605,9 @@ proc makewindow {} {
>  bind .  updatecommits
>  bindmodfunctionkey Shift 5 reloadcommits
>  bind .  showrefs
> +bind .  {show_tree_of_references_dialog "localBranches"}
> +bind .  {show_tree_of_references_dialog "remoteBranches"}
> +bind .  {show_tree_of_references_dialog "tags"}
>  bindmodfunctionkey Shift 4 {newview 0}
>  bind .  edit_or_newview
>  bind . <$M1B-q> doquit
> @@ -10146,6 +10153,116 @@ proc rmbranch {} {
>  run refill_reflist
>  }
>  
> +# Display a tree view of local branches, remote branches, and tags according 
> to view_type.
> +#
> +# @param string view_type
> +#Must be one of "localBranches", "remoteBranches", or "tags".
> +#
> +proc show_tree_of_references_dialog {view_type} {
> +global NS
> +global treefilelist
> +global headids tagids
> +
> +switch -- $view_type {
> + "localBranches" {
> + set dialogName "Local Branches"
> + set top .show_tree_of_local_branches
> + set listOfReferences [lsort [array names headids -regexp 
> {^(?!remotes/)} ]]
> + set truncateFrom 0
> + }
> + "remoteBranches" {
> + set dialogName "Remote Branches"
> + set top .show_tree_of_remote_branches
> + set listOfReferences [lsort [array names headids -regexp 
> {^remotes/} ]]
> + set truncateFrom 8
> + }
> + "tags" {
> + set dialogName "Tags"
> + set top .show_tree_of_tags
> + set listOfReferences [lsort [array names tagids]]
> + set truncateFrom 0
> + }
> +}
> +
> +if {[winfo exists $top]} {
> + raise $top
> + return
> +}
> +
> +ttk_toplevel $top
> +wm title $top [mc "$dialogName: %s" [file tail [pwd]]]
> +wm geometry $top "600x900"

Do you really need to do this?  A fixed size like this is inevitably
going to be too big for some users and too small for others.

> +
> +make_transient $top .
> +
> +## See http://www.tkdocs.com/tutorial/tree.html
> +ttk::treeview $top.referenceList -xscrollcommand 
> "$top.horizontalScrollBar set" -yscrollcommand "$top.verticalScrollBar set"

We still have the option for people to run without ttk, in case
someone is still using an old Tcl/Tk version or just doesn't like the
ttk widgets.  However, there isn't an equivalent of ttk::treeview in
the older Tk widget set.  It would be OK to omit the new menu entries
or to disable them if $use_ttk is false, but I don't want to have menu
entries that will always cause gitk to blow up when $use_ttk is false.

We possibly should consider converting the file list view to use a
ttk::treeview when $use_ttk is true.

Paul.

Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references

[Paul Mackerras]

On Tue, Dec 20, 2016 at 10:01:15AM -0500, Marc Branchaud wrote:
> On 2016-12-19 11:44 AM, Michael Haggerty wrote:
> >This patch series changes a bunch of details about how remote-tracking
> >references are rendered in the commit list of gitk:
> 
> Thanks for this!  I like the new, compact look very much!
> 
> That said, I remember when I was a new git user and I leaned heavily on gitk
> to understand how references worked.  It was particularly illuminating to
> see the remote references distinctly labeled, and the fact that they were
> "remotes/origin/foo" gave me an Aha! moment where I came to understand that
> the refs hierarchy is more flexible than just the conventions coded into git
> itself.  I eventually felt free to create my own, private ref hierarchies.
> 
> I am in no way opposed to this series.  I just wanted to point out that
> there was some utility in those labels.  It makes me think that it might be
> worthwhile for gitk to have a "raw-refs" mode, that shows the full
> "refs/foo/bar/baz" paths of all the heads, tags, and whatever else.  It
> could be a useful teaching tool for git.

Do you think we should have a checkbox in the preferences dialog to
select whether to display the long form or the short form?

Paul.

Re: [PATCH 0/3] gitk: memory consumption improvements

[Paul Mackerras]

On Mon, Nov 07, 2016 at 07:54:28PM +0100, Markus Hitter wrote:
> 
> List, Paul,
> 
> after searching for a while on why Gitk sometimes consumes exorbitant amounts 
> of memory I found a pair of minor issues and also a big one: the text widget 
> comes with an unlimited undo manager, which is turned on be default. 
> Considering that each line is inserted seperately, this piles up a huuuge 
> undo stack ... for a read-only text widget. Simply turning off this undo 
> manager saves about 95% of memory when viewing large commits (with tens of 
> thousands of diff lines).
> 
> 3 patches are about to follow:
> 
>  - turn off the undo manager,
> 
>  - forget already closed file descriptors and
> 
>  - forget the 'commitinfo' array on a reload to enforce reloading it.
> 
> I hope this finds you appreciation.

Thanks for the good work in tracking this down and making the patches.
I have applied the series.  Apologies for slow response (life has been
extremely busy for me this year).

Paul.

Re: [PATCH] gitk: Fix Japanese translation for "marked commit"

[Paul Mackerras]

On Tue, Oct 25, 2016 at 12:35:10AM +0900, Satoshi Yasushima wrote:
> Signed-off-by: Satoshi Yasushima 
> ---
>  po/ja.po | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

Applied, thanks,

Paul.

Re: Proposal for an increased `gitk` cohesion with `git stash`.

[Paul Mackerras]

Hi Uxio,

On Thu, Sep 08, 2016 at 03:41:29PM +0200, Uxío Prego wrote:
> Hello, please forgive me for not introducing me.
> 
> +---+
> |Description|
> +---+
> 
> Patch for showing all stashes in `gitk`.
> 
> +---+
> |The problem|
> +---+
> 
> Being `gitk` one of the best tools for navigating and understanding graphs
> of git repo revs, I got used to have it for home use, some years ago, soon
> for office use too.
> 
> At some point I got used to invoke always `gitk --all` in order to keep
> tracking of tags when using the program for building, when possible, stable
> versions of any GNU/Linux software I would want to use.
> 
> It seems `gitk --all` uses `git show-ref` for showing remotes information.
> A side effect of this is that the most recent stash gets shown in `gitk
> --all`. After learning what the stash was, I got used to it.
> 
> Later, when at jobs, I got used to have a stash on all working branch tips.
> So I often would have several stashes in `git stash list` but only the last
> one in `gitk --all`. That annoyed me for about a year, finally I got
> working in `gitk` to show a stash status more similar to what `git stash
> list` shows.
> 
> +---+
> |The feature|
> +---+
> 
> Show all stashes in `gitk` instead of only the last one.

This seems like a good feature, although I don't use stashes myself.

> +--+
> |Why it's desirable|
> +--+
> 
> In order to have better visual control when working on repos that have
> several active branches and there are needed quick context changes between
> them with the features that `git stash [apply [STASHNAME]| list | pop
> [STASHNAME]| push | save | show [[-p] STASHNAME]]`.
> 
> In order to have a better cohesion between the mentioned features and `gitk
> --all`.
> 
> ++
> |Caveats and side effects|
> ++
> 
> With this patch several side effects happen:
> 
> * Stashes are shown even invoking `gitk`, not only when running `gitk
> --all`. If this is a problem, I can keep working in the patch to avoid this.
> 
> * The most recent stash, which was previously shown as 'stash' because its
> corresponding `git show-ref` output line reads 'refs/stash', gets shown as
> 'stash@{0}'. Not removing lines with 'stash' when calling `git show-ref`
> gets it shown both as 'stash' as usual and as 'stash@{0}'.
> 
> +--+
> |Non-obvious design choices|
> +--+
> 
> There are many improvable things consequence of never having edited
> anything Tcl before this. Besides, its working for me as a proof of
> concept, both in Debian 7 Wheezy and 8 Jessie.
> 
> The origin document of the following diff is `gitk` as it ships in Debian 8
> Jessie. I have not tried yet but if required I would be willing to rework
> it for the repo master.

A patch against the latest version in my git repo at
git://ozlabs.org/~paulus/gitk would be better.

> `gitk-stash-list-ids.sh` is a shell script that performs `git stash list
> --pretty=format:"%H"`, i.e. show rev hashes for all stashes in the fashion
> that `git rev-list --all` does its default output. I did this because I
> could not work out a better pure Tcl solution.

Hmmm, I don't want gitk to have to depend on an external script.
It should be possible to make Tcl execute the git command directly,
though (see below).

> ++
> |Unified diff follows|
> ++
> 
> 0:10:1473338052:uprego@uxio:~$ diff -u /usr/bin/gitk-deb8-vanilla
> /usr/bin/gitk-deb8-multistash
> --- /usr/bin/gitk-deb8-vanilla  2016-08-29 10:07:06.507344629 +0200
> +++ /usr/bin/gitk-deb8-multistash   2016-09-08 14:36:35.382476634 +0200
> @@ -401,6 +401,10 @@
> 
>  if {$vcanopt($view)} {
> set revs [parseviewrevs $view $vrevs($view)]
> +set stashesfd [open [concat | gitk-stash-list-ids.sh] r]

set stashesfd [open [list | git stash list {--pretty=format:%H}] r]

> +while {[gets $stashesfd stashline] >= 0} {
> +set revs [lappend revs $stashline]
> +}

Could this ever take a long time?  The UI is unresponsive while we're
in this loop.  If this is always quick (even on large repos), OK.  If
it could take a long time then we'll need a file event handler.

> if {$revs eq {}} {
> return 0
> }
> @@ -1778,7 +1782,7 @@
>  foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
> catch {unset $v}
>  }
> -set refd [open [list | git show-ref -d] r]
> +set refd [open [list | git show-ref -d | grep -v stash] r]

If I had a branch called "dont-use-a-stash-for-this", would it get
filtered out by this grep?  It seems like it would, and we don't want
it to.  So the filtering needs to be more exact here.

>  while {[gets $refd line] >= 0} {
> if {[string index $line 40] ne " "} continue
> set id [string range $line 0 39]
> @@ -1811,6 +1815,16 @@
> }
>  }
>  catch {

Re: [PATCH v4] gitk: Add Portuguese translation

[Paul Mackerras]

On Wed, May 11, 2016 at 08:01:33PM +, Vasco Almeida wrote:
> Signed-off-by: Vasco Almeida 
> ---
> 
>  Oops, fix typo.

Thanks, applied.

Paul.

Re: [PATCH] Gitk Inotify support

[Paul Mackerras]

On Sat, Jun 11, 2016 at 04:06:36PM +0200, Florian Schüller wrote:
> >From 74d2f4c1ec560b358fb50b8b7fe8282e7e1457b0 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Florian=20Sch=C3=BCller?= 
> Date: Thu, 9 Jun 2016 22:54:43 +0200
> Subject: [PATCH] first support for inotify
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Just automatically update gitk when working in a terminal on the same repo
> 
> Open points for now:
>  - release watches for deleted directories seems to
>cause problems in tcl-inotify (so I don't)
>I'm not sure how often that happens in ".git/"
>  - I only call "updatecommits" and I don't know if there is a usecase
>where I should be calling "reloadcommits"

Thanks for the patch.  It's a nice idea.  I think it needs a couple of
improvements, though, to make it work even better:

* Some users might not want this behaviour, so we need an option in
  the preferences pane to enable/disable this.

* I would expect that the updates to the files in .git would come in
  bursts, so we should probably do something like wait until (say) one
  second has elapsed since the last notification, without any more
  notifications, before starting the update.

* We probably want to rate-limit the updates, since on a large tree
  (e.g. the Linux kernel) the update can take several seconds and the
  UI is less responsive during that time.

Paul.

Re: [PATCH v2 0/2] gitk: Two improvements to the branch context menu

[Paul Mackerras]

On Sat, Mar 19, 2016 at 07:31:32PM +0100, Rogier Goossens wrote:
> Hi,
> 
> Hereby the revised patches.
> 
> Changes since v1:
> - Rebased on latest master
> - Made the changes you suggested
> - Moved 'rename branch' menu option above 'delete branch'
> - Cleaned up some code duplication that the previous patches 
> introduced.

Thanks, series applied.

Paul.

Re: [PATCH v3] gitk: Fix missing commits when using -S or -G

[Paul Mackerras]

On Sat, Jun 04, 2016 at 10:47:16AM +0200, Stefan Dotterweich wrote:
> When -S or -G is used as a filter option, the resulting commit list
> rarely contains all matching commits. Only a certain number of commits
> are displayed and the rest are missing.
> 
> "git log --boundary -S" does not return as many boundary commits as you
> might expect. gitk makes up for this in closevargs() by adding missing
> parent (boundary) commits. However, it does not change $numcommits,
> which limits how many commits are shown. In the end, some commits at the
> end of the commit list are simply not shown.
> 
> Change $numcommits whenever a missing parent is added.
> 
> Signed-off-by: Stefan Dotterweich 

Thanks, applied, with slight tweaks to the commit message.

Paul.

Re: [PATCH] gitk: Makefile: create install bin directory

[Paul Mackerras]

On Thu, May 05, 2016 at 05:46:32PM +, Vasco Almeida wrote:
> Force creation of destination bin directory. Before this commit, gitk
> would fail to install if this directory didn't already exist.
> 
> Signed-off-by: Vasco Almeida 

Thanks, applied (with slight tweak to commit message).

Paul.

Re: [PATCH v3 1/2] gitk: alter the ordering for the "Tags and heads" view

[Paul Mackerras]

On Sun, Mar 27, 2016 at 11:06:07AM -0400, Michael Rappazzo wrote:
> In the "Tags and heads" view, the list of refs is globally sorted.
> Because of this, the list of local refs (heads) can be interrupted by the
> list of remote refs.  This change re-orders the view to be: local refs,
> remote refs tracked by local refs, remote refs, tags, and then other refs.
> 
> Signed-off-by: Michael Rappazzo 

This all looks OK except for the fact that the loop immediately below
the code you've modified (the loop that adds or deletes lines from the
actual displayed list) relies on the entries being in sorted order.
With your patch the entries are no longer strictly in sorted order, so
that display update loop will have to become a bit smarter too.  As it
is, I think that there will be cases where we will delete a lot of
lines and then re-add them.  If the user had scrolled the list to a
particular point that was within these deleted lines, the display will
scroll away from that point, which will be annoying.

Paul.

Re: gitk: avoid obscene memory consumption

[Paul Mackerras]

On Sun, Nov 06, 2016 at 11:28:37AM +0100, Markus Hitter wrote:
> 
> Thanks for the positive comments.
> 
> TBH, the more I think about the problem, the less I'm satisfied with the 
> solution I provided. Including two reasons:
> 
> - The list of files affected to the right is still complete and clicking a 
> file name further down results in nothing ... as if the file wasn't part of 
> the diff.
> 
> - Local searches. Cutting off diffs makes them unreliable. Global searches 
> still work, but actually viewing a search result in the skipped section is no 
> longer possible.
> 
> So I'm watching out for better solutions. So far I can think of these:
> 
> - Storing only the actually viewed diff. It's an interactive tool, so there's 
> no advantage in displaying the diff in 0.001 seconds over viewing it in 0.1 
> seconds. As far as I can see, Gitk currently stores every diff it gets a hold 
> of forever.

It does?  That would be a bug. :)

> 
> - View the diff sparsely. Like rendering only the actually visible portion.
> 
> - Enhancing ctext. This reference diff has 28 million characters, so there 
> should be a way to store this with color information in, let's say, 29 MB of 
> memory.

Tcl uses Unicode internally, I believe, so 57MB, but yes.

Paul.

Re: gitk: avoid obscene memory consumption

[Paul Mackerras]

On Fri, Nov 04, 2016 at 03:45:09PM -0700, Stefan Beller wrote:
> On Fri, Nov 4, 2016 at 12:49 PM, Markus Hitter  wrote:
> >
> > Hello all,
> 
> +cc Paul Mackeras, who maintains gitk.

Thanks.

> >
> > after Gitk brought my shabby development machine (Core2Duo, 4 GB RAM, 
> > Ubuntu 16.10, no swap to save the SSD) to its knees once more than I'm 
> > comfortable with, I decided to investigate this issue.
> >
> > Result of this investigation is, my Git repo has a commit with a diff of 
> > some 365'000 lines and Gitk tries to display all of them, consuming more 
> > than 1.5 GB of memory.
> >
> > The solution is to cut off diffs at 50'000 lines for the display. This 
> > consumes about 350 MB RAM, still a lot. These first 50'000 lines are shown, 
> > followed by a copyable message on how to view the full diff on the command 
> > line. Diffs shorter than this limit are displayed as before.

That sounds reasonable.

> 
> Bikeshedding: I'd argue to even lower the number to 5-10k lines.

I could go with 10k.

> 
> >
> > To test the waters whether such a change is welcome, here's the patch as I 
> > currently use it. If this patch makes sense I'll happily apply change 
> > requests and bring it more in line with Git's patch submission expectations.
> 
> I have never contributed to gitk myself,
> which is hosted at git://ozlabs.org/~paulus/gitk
> though I'd expect these guide lines would roughly apply:
> https://github.com/git/git/blob/master/Documentation/SubmittingPatches

Paul.

Re: [PATCH v2] gitk: Fix missing commits when using -S or -G

[Paul Mackerras]

On Fri, May 06, 2016 at 02:16:54PM +0200, Stefan Dotterweich wrote:
> When -S or -G is used as a filter option, the resulting commit list
> rarely contains all matching commits. Only a certain number of commits
> are displayed and the rest are missing.
> 
> "git log --boundary -S" does not return as many boundary commits as you
> might expect. gitk makes up for this in closevargs() by adding missing
> parent (boundary) commits. However, it does not change $numcommits,
> which limits how many commits are shown. In the end, some commits at the
> end of the commit list are simply not shown.
> 
> Change $numcommits whenever a missing parent is added.

Nice catch; however, we should only update numcommits if the commits
are for the current view, i.e. if $v == $curview.

Do you want to update the patch?  If you prefer, I can update the
patch and put a note in the commit message about the issue.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q] updates to gitk, git-gui and git-svn for 2.8?

[Paul Mackerras]

Hi Junio,

> If there are pending updates for the upcoming release, please let me
> know and tell me what to pull.

Please pull from my gitk repository.

Thanks,
Paul.

The following changes since commit 0de75aafb66b22a04e6c90c0baf15dca11bddb3c:

  Merge branch 'ja.po' of https://github.com/qykth-git/gitk (2015-12-19 
13:33:16 +1100)

are available in the git repository at:

  git://ozlabs.org/~paulus/gitk.git 

for you to fetch changes up to 22a713c72df8b6799c59287c50cee44c4a6db51e:

  gitk: Follow themed bgcolor in help dialogs (2016-03-19 14:12:21 +1100)


Alexander Shopov (1):
  gitk: Update Bulgarian translation (311t)

Guillermo S. Romero (1):
  gitk: Follow themed bgcolor in help dialogs

Jean-Noel Avila (2):
  gitk: Update French translation (311t)
  gitk: fr.po: Sync translations with git

Ralf Thielow (1):
  gitk: Update German translation

 gitk |   8 +-
 po/bg.po | 656 
 po/de.po |  79 +++---
 po/fr.po | 849 +++
 4 files changed, 788 insertions(+), 804 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] gitk: add an option to enable sorting the "Tags and heads" view by ref type

[Paul Mackerras]

On Fri, Mar 18, 2016 at 02:51:37PM -0400, Michael Rappazzo wrote:
> Signed-off-by: Michael Rappazzo 

This looks to me like the kind of thing that could have a checkbox in
the Preferences window and get saved on disk along with other
preferences, rather than only being available via a command-line
option.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] gitk: Add a 'rename' option to the branch context menu

[Paul Mackerras]

On Fri, Jan 15, 2016 at 10:38:49PM +0100, Rogier Goossens wrote:
> 
> Signed-off-by: Rogier Goossens 

This is a nice idea; I just have some comments about the Tcl here:

> @@ -9756,15 +9831,19 @@ proc headmenu {x y id head} {
>  stopfinding
>  set headmenuid $id
>  set headmenuhead $head
> -set state normal
> +array set state {0 normal 1 normal 2 normal 3 normal}
>  if {[string match "remotes/*" $head]} {
> - set state disabled
> + set state(0) disabled
> + set state(1) disabled
> + set state(2) disabled

Why not "array set state {0 disabled 1 disabled 2 disabled}" instead?

>  }
>  if {$head eq $mainhead} {
> - set state disabled
> + set state(0) disabled
> + set state(1) disabled

Similarly, "array set state {0 disabled 1 disabled}".

> +}
> +foreach i {0 1 2 3} {

Why do you go up to 3 when we never disable the 3rd entry?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Follow themed bgcolor in help dialogs

[Paul Mackerras]

On Thu, Feb 04, 2016 at 03:32:19AM +0100, Guillermo S. Romero wrote:
> Make Help > About & Key bindings dialogs readable if theme
> has changed font color to something incompatible with white.
> 
> Signed-off-by: Guillermo S. Romero 

Thanks, applied.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] gitk: fr.po: Update translation (311t)

[Paul Mackerras]

Thanks, applied both patches.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: update German translation

[Paul Mackerras]

Thanks, applied.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Update Bulgarian translation (311t)

[Paul Mackerras]

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] gitk: alter the ordering for the "Tags and heads" view

[Paul Mackerras]

On Fri, Mar 18, 2016 at 02:51:36PM -0400, Michael Rappazzo wrote:
> In the "Tags and heads" view, the list of refs is globally sorted.
> Because of this, the list of local refs (heads) can be interrupted by the
> list of remote refs.  This change re-orders the view to be: local refs,
> remote refs tracked by local refs, remote refs, tags, and then other refs.

This seems like a nice idea, and could lead on to having a section that
can be opened and closed for each of these categories.  However, I
have some comments on the implementation:

> @@ -9933,35 +9933,71 @@ proc refill_reflist {} {
>  global curview
>  
>  if {![info exists showrefstop] || ![winfo exists $showrefstop]} return
> -set refs {}
> +set localrefs {}
> +set remoterefs {}
> +set locally_tracked_remote_refs {}
> +set tagrefs {}
> +set otherrefs {}
>  foreach n [array names headids] {
> - if {[string match $reflistfilter $n]} {
> + if {![string match "remotes/*" $n] && [string match $reflistfilter $n]} 
> {
>   if {[commitinview $headids($n) $curview]} {
> - lappend refs [list $n H]
> + lappend localrefs [list $n H]
> + catch {set remote_name [exec git config --get branch.$n.remote]}
> + if {$remote_name ne ""} {
> + catch {set remote_ref [exec git config --get 
> branch.$n.merge]}
> + set remote_ref [string map {"refs/heads/" ""} $remote_ref]
> + set locally_tracked_remote_ref 
> "remotes/$remote_name/$remote_ref"
> + set upstream_exists ""
> + catch {set upstream_exists [exec git rev-parse --verify 
> $locally_tracked_remote_ref]}
> + if {$upstream_exists ne ""} {
> + if {[lsearch $locally_tracked_remote_refs [list 
> $locally_tracked_remote_ref H]] < 0} {
> + lappend locally_tracked_remote_refs [list 
> $locally_tracked_remote_ref H]
> + }
> + }
> + }

I'm worried about the number of external git invocations we're
potentially doing here, and how long that would take when you have a
lot of heads.  Can we cache the results perhaps?  Or is there a way to
do a single git command and get a list of tracking branches with their
remotes etc.?

Also, the default for lsearch is glob-style matching.  It's unlikely
that ref names would have any of *?[\ in them, but AFAIK it's not
impossible.  You probably want -exact in there.

Further, the kind of thing you are using lsearch for can often be done
more efficiently using an array (which becomes essentially a hash
table underneath).

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFPR] updates for 2.7?

[Paul Mackerras]

On Tue, Dec 15, 2015 at 03:09:44PM -0800, Junio C Hamano wrote:
> Git 2.7-rc1 has just been tagged, and the remainder of the year will
> be for the stabilization, fixes to brown-paper-bag bugs, reverts of
> regressions, etc., but I haven't seen updates to the various
> subsystems you guys maintain for some time.  Please throw me "this
> is a good time to pull and here are the updates" message in the
> coming few weeks.

Please do a pull from git://ozlabs.org/~paulus/gitk.git to get:

* Some improvements to gitk appearance, particularly on high DPI monitors
* Translation updates for Japanese and Swedish.

Thanks,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] gitk: match ttk fonts to gitk fonts

[Paul Mackerras]

On Tue, Dec 08, 2015 at 08:05:50AM +0100, Giuseppe Bilotta wrote:
> The fonts set in setoptions aren't consistently picked up by ttk, who
> uses its own predefined fonts. This is noticeable when switching
> between using and not using ttk with custom fonts or in HiDPI settings
> (where the default TTK fonts do _not_ respect tk sclaing).
> 
> Fix by mapping the ttk fontset to the one used by gitk internally.
> 
> Signed-off-by: Giuseppe Bilotta 

Thanks, applied both this and the following patch.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] gitk: add -C commandline parameter to change path

[Paul Mackerras]

On Mon, Nov 09, 2015 at 01:45:22PM +0200, Juha-Pekka Heikkila wrote:
> This patch adds -C (change working directory) parameter to
> gitk. With this parameter, instead of need to cd to directory
> with .git folder, one can point the correct folder from
> commandline.
> 
> Signed-off-by: Juha-Pekka Heikkila 

Thanks.

While I like the idea, there are a couple of minor problems with the
patch.  First, the Documentation directory is in Junio's tree, not
mine, so the change to gitk and the change to Documentation need to be
separated.  Secondly, please use 4-space indentation rather than
8-space for consistency with the rest of the file.  See also the
comments below.

> + "-C*" {
> + if {[string length $arg] < 3} {
> + incr i
> + set cwd_path [lindex $argv [expr {$i}]]

No need to say [expr {$i}] here; [lindex $argv $i] works just fine.

Also, if i is now >= [llength $argv], we'll get an empty string in
cwd_path.  Is that what you meant?  Shouldn't we display an
appropriate error message instead of trying to cd to ""?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: sv.po: Update Swedish translation (311t)

[Paul Mackerras]

Thanks, applied.

Paul.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [gmane.comp.version-control.git] [PATCH 0/4] gitk crash fix and locale updates

[Paul Mackerras]

On Mon, Oct 26, 2015 at 05:16:20PM -0700, Junio C Hamano wrote:
> Ping.  What do you think of these?  It appears that quite a many
> people are getting bitten by the issues this series addresses.

Yes, sorry about that.  I have applied a patch from Beat Bolli fixing
the basic issue, since his patch was the same as Takashi's first patch
and was posted earlier.  I have also applied 2-4 of Takashi's series
plus some other translation updates.  I have pushed all that out to
git://ozlabs.org/~paulus/gitk.git.

Please pull whenever is convenient for you.

Regards,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] gitk crash fix and locale updates

[Paul Mackerras]

On Tue, Oct 20, 2015 at 02:33:00PM +0200, Takashi Iwai wrote:
> Hi,
> 
> the recent change in gitk to support the menu accelerator broke the
> invocation with --all option in non-English locales.  Also, the whole
> menu translations are gone by this, too.  This patchset tries to
> address these issues.

Thanks for the series.  The patch 1/4 is the same as a patch from Beat
Bolli that I just applied, so I left out your 1/4 and applied 2, 3,
and 4.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: add missing accelerators

[Paul Mackerras]

On Wed, Sep 30, 2015 at 09:50:11PM +0200, Beat Bolli wrote:
> In d99b4b0de27a ("gitk: Accelerators for the main menu", 2015-09-09),
> accelerators were added to allow efficient keyboard navigation. One
> instance of the strings "Edit view..." and "Delete view" were left
> without the ampersand.
> 
> Add the missing ampersand characters to unbreak our international
> users.
> 
> Signed-off-by: Beat Bolli 
> Cc: Paul Mackerras 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: l10n: Update Catalan translation

[Paul Mackerras]

On Mon, Oct 05, 2015 at 10:26:12PM -0600, Alex Henrie wrote:
> The gitk included in git 2.6.0 crashes if run from a Catalan locale.
> I'm hoping that a translation update will fix this.
> 
> Signed-off-by: Alex Henrie 

Should actually be fixed by a patch from Beat Bolli that I just applied,
but I applied your patch also.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: accelerators for the main menu

[Paul Mackerras]

On Wed, Sep 09, 2015 at 03:20:53PM +0200, Giuseppe Bilotta wrote:
> This allows fast, keyboard-only usage of the menu (e.g. Alt+V, N to open a
> new view).
> 
> Signed-off-by: Giuseppe Bilotta 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH, RESEND] gitk: adjust the menu line numbers to compensate for the new entry

[Paul Mackerras]

On Tue, Sep 08, 2015 at 01:16:37AM +0200, Beat Bolli wrote:
> Commit d835dbb9 ("gitk: Add a "Copy commit summary" command",
> 2015-08-13) in the upstream gitk repo added a new context menu entry.
> Therefore, the line numbers of the entries below the new one need to be
> adjusted when their text or state is changed.
> 
> Signed-off-by: Beat Bolli 
> Cc: Paul Mackerras 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Update Bulgarian translation (307t)

[Paul Mackerras]

On Sun, Jun 28, 2015 at 11:28:13PM +0300, a...@kambanaria.org wrote:
> From: Alexander Shopov 
> 
> Signed-off-by: Alexander Shopov 
> ---
>  po/bg.po | 19 ---
>  1 file changed, 8 insertions(+), 11 deletions(-)

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] gitk: Add a "Copy commit summary" command

[Paul Mackerras]

On Sat, Jul 18, 2015 at 01:15:39PM +0200, Beat Bolli wrote:
> When referring to earlier commits in commit messages or other text, one
> of the established formats is
> 
>  ("", )
> 
> Add a "Copy commit summary" command to the context menu that puts this
> text for the currently selected commit on the clipboard. This makes it
> easy for our users to create well-formatted commit references.
> 
> The  is produced with the %h format specifier to make it
> unique. Its length can be controlled with the gitk preference
> "Auto-select SHA1 (length)", or, if this preference is set to its
> default value (40), with the Git config setting core.abbrev.
> 
> Signed-off-by: Beat Bolli 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Alter the ordering for the "Tags and heads" view

[Paul Mackerras]

On Tue, Jun 02, 2015 at 07:11:10AM -0400, Michael Rappazzo wrote:
> In the "Tags and heads" view, the list of refs is globally sorted.
> The list of local refs (heads) is separated by the remote refs.  This
> change re-orders the view toi be: local refs, remote refs tracked by
> local refs, remote refs, tags, and then other refs
> 
> Signed-off-by: Michael Rappazzo 

Sorry it's taken me so long to get around to reviewing this.  I have a
couple of comments:

> ---
>  gitk-git/gitk | 48 ++--
>  1 file changed, 42 insertions(+), 6 deletions(-)
> 
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index 9a2daf3..431a6a1 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -9879,35 +9879,71 @@ proc refill_reflist {} {
>  global curview
>  
>  if {![info exists showrefstop] || ![winfo exists $showrefstop]} return
> -set refs {}
> +set localrefs {}
> +set remoterefs {}
> +set locally_tracked_remote_refs {}
> +set tagrefs {}
> +set otherrefs {}
>  foreach n [array names headids] {
> - if {[string match $reflistfilter $n]} {
> + if {![string match "remotes/*" $n] && [string match $reflistfilter $n]} 
> {
> + if {[commitinview $headids($n) $curview]} {
> + lappend localrefs [list $n H]
> + catch {set remote_name [exec git config --get branch.$n.remote]}
> + if {$remote_name ne ""} {

First off, if the git config command fails for any reason and returns
an error status, the set command won't get done and $remote_name will
either be undefined or will have whatever value it had before.  If it
is undefined then the if statement is going to throw an error.  I
don't think that is what you meant to happen.  This same problem will
occur for other variables such as $remote_ref and $exists.

Secondly, I'm not very happy about doing all these external git
commands every time we run refill_reflist.  Couldn't we cache which
remote each local branch is tracking?  We would then throw away and
reload the cache in rereadrefs.  Most executions of refill_reflist
would then not need to do any external git commands at all.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] gitk: Add a "Copy commit summary" command

[Paul Mackerras]

On Tue, Jul 21, 2015 at 12:19:23PM +0200, Beat Bolli wrote:
> Guys,
> 
> can I get a Yea or Nay for this patch?
> 
> Does it go in via Paul's gitk repo or directly through Junio?

I'll put it in.  It goes into my repo and from there into Junio's.
I'm on vacation and travelling this week, so please be patient.

Regards,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] gitk: Add a "Copy commit summary" command

[Paul Mackerras]

On Fri, Jul 17, 2015 at 08:30:24AM -0700, Junio C Hamano wrote:
> Paul Mackerras  writes:
> 
> > We have an item in the preferences menu to control the SHA1 length
> > that is automatically selected when going to a new commit.  It's
> > stored in the variable $autosellen.  That seems like it would be a
> > reasonable choice for the SHA1 length to use here.
> 
> Reusing a configuration that is used to control something similar
> sounds sensible to me.
> 
> > The only possible
> > problem is that it defaults to 40 and so might give an overly long
> > result for some users.  Maybe you could use $autosellen but limit it
> > to at most 12 or 16 or something like that.
> 
> How is the thing that is "automatically selected when going to a new
> commit" used by the end user?  What is the reason why people may
> want to configure it?  I understand that this is the string that
> goes into the selection buffer, so presumably people are using this
> selection to paste elsewhere?  If so, that sounds like very similar
> to Beat's use case---perhaps if 40 is too long for Beat's use case
> as a sensible default, then it is also too long for its original use
> case?

It's used for pasting into commit messages and emails, and it's used
for pasting onto the command line when typing git commands.  For the
second, the length doesn't matter; the limit was added for the first
case.

> Or do you expect it to be common to want to use autosellen set to 40
> and Beat's abbrev len set to much shorter, e.g. 16?  If so they may
> deserve two different settings, with different defaults.

I would think that if $autosellen is 40 it's almost certainly because
the user hasn't found that control in the preferences window. :)

> Artificially limiting it to 12 or 16 does not sound all that
> sensible, though.

Adding --abbrev=$autosellen if $autosellen is not 40 sounds like it
would do what we want.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] gitk: Add a "Copy commit summary" command

[Paul Mackerras]

On Thu, Jul 16, 2015 at 05:29:25PM +0200, Beat Bolli wrote:
> When referring to earlier commits in commit messages or other text, one
> of the established formats is
> 
>  ("", )
> 
> Add a "Copy commit summary" command to the context menu that puts this
> text for the currently selected commit on the clipboard. This makes it
> easy for our users to create well-formatted commit references.

I really like this idea, but as others have noted, 8 characters may
not be the right choice for the SHA1 length in all cases.

We have an item in the preferences menu to control the SHA1 length
that is automatically selected when going to a new commit.  It's
stored in the variable $autosellen.  That seems like it would be a
reasonable choice for the SHA1 length to use here.  The only possible
problem is that it defaults to 40 and so might give an overly long
result for some users.  Maybe you could use $autosellen but limit it
to at most 12 or 16 or something like that.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk won't show notes?

[Paul Mackerras]

On Wed, Apr 08, 2015 at 01:51:40PM +0200, Michael J Gruber wrote:
> Phillip Susi venit, vidit, dixit 07.04.2015 19:08:
> > On 4/7/2015 10:13 AM, Michael J Gruber wrote:
> >> Seriously: gitk knows F5 and Shift-F5 for refresh, and I think the 
> >> latter is the thorougher refreshment.
> > 
> > Neither one makes newly added notes show up.  The only way seems to be
> > to close and restart gitk.  Looks like a bug.
> > 
> > 
> 
> Apparently, gitk rereads the refs but not commits it has read already -
> and the commit reading includes the notes lookup.
> 
> Unfortunately, my wish-fu is lacking. But I'll cc the master.
> 
> Paulus: None of updatecommits, reloadcommits and rereadrefs seem to
> reread the notes of a commit that has been displayed already if the
> notes have changed (but the other refs have not).

As far as shift-F5/reloadcommits is concerned, it looks like I should
be unsetting commitinfo in reloadcommits.

However, I agree gitk should refresh the notes in updatecommits as
well, but that will take more work.  Is git notes list the best way to
find out all the current notes?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/2] gitk: Show the rev(s) the user specified on the command line in the window title.

[Paul Mackerras]

On Tue, Jan 06, 2015 at 12:52:00PM -0500, Marc Branchaud wrote:
> Signed-off-by: Marc Branchaud 
> ---
> 
> I often open multiple gitk windows in the same working directory to examine
> other branches or refs in the repo.  This change allows me to distinguish
> which window is showing what.
> 
> This is an RFC because it doesn't behave great with views.  I don't use views
> at all, so this doesn't bother me.  I'm not too sure what should be displayed
> if the user changes views -- probably the view name, but I'm not sure how to
> get a that in the code.

The view name is in $viewname($curview).  If that is "Command line"
you probably want to show some selected command line arguments.

Using $vrevs($curview) seems about right, though it will contain
"--gitk-symmetric-diff-marker" in some situations, which is an
internal thing that we don't want to show externally.  You should
probably filter it out.

The patch will need a proper description before I can apply it, of
course.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Fix bad English grammar "Matches none Commit Info"

[Paul Mackerras]

On Thu, Apr 02, 2015 at 03:05:06PM -0600, Alex Henrie wrote:
> Signed-off-by: Alex Henrie 
> ---
>  gitk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gitk b/gitk
> index 9a2daf3..30fcd30 100755
> --- a/gitk
> +++ b/gitk
> @@ -4066,7 +4066,7 @@ set known_view_options {
>  {committer t15  .  "--committer=*"  {mc "Committer:"}}
>  {loginfo   t15  .. "--grep=*"   {mc "Commit Message:"}}
>  {allmatch  b.. "--all-match"{mc "Matches all Commit Info 
> criteria"}}
> -{igrep b.. "--invert-grep"  {mc "Matches none Commit Info 
> criteria"}}
> +{igrep b.. "--invert-grep"  {mc "Matches no Commit Info 
> criteria"}}

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] gitk: Rearrange window title to be more conventional.

[Paul Mackerras]

On Mon, Mar 23, 2015 at 10:18:16AM -0400, Marc Branchaud wrote:
> Signed-off-by: Marc Branchaud 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Remove mc parameter from proc show_error

[Paul Mackerras]

On Thu, Apr 02, 2015 at 03:05:35PM -0600, Alex Henrie wrote:
> This partially reverts commit 8d849957d81fc0480a52570d66cc3c2a688ecb1b.

... and brings back the bug that 8d849957d81f solves, as far as I can
see.  If that's not the case then you need to explain that in the
patch description.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: sv.po: Update Swedish translation (305t0f0u)

[Paul Mackerras]

On Fri, Mar 27, 2015 at 10:34:25AM +0100, Peter Krefting wrote:
> Please find attached (for text encoding reasons) an update to the Swedish
> translation for gitk.

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk drawing bug

[Paul Mackerras]

On Fri, Apr 03, 2015 at 09:28:00PM -0400, Martin d'Anjou wrote:
> On 15-04-03 07:05 PM, Alex Henrie wrote:
> >2015-02-18 12:27 GMT-07:00 Martin d'Anjou :
> >>It appears I have uncovered inconsistent behaviour in gitk. Looks like
> >>a bug. I have a picture here:
> >>https://docs.google.com/document/d/19TTzGD94B9EEIrVU5mRMjfJFvF5Ar3MlPblRJfP5OdQ/edit?usp=sharing
> >>
> >>Essentially, when I hit shift-F5, it sometimes draw the history
> >>differently (still valid, but drawn differently). There is no change
> >>in the repository between the shift-F5 keystrokes.

That's not a bug, it's a consequence of the fact that gitk is designed
to be fast.  It only lays out as much of the graph is visible plus a
little more, not the whole graph, and it doesn't use any global
analysis.  The reason for that is speed.  Gitk is usable on a
repository with half a million commits, such as the linux kernel, and
to achieve that we can't afford to do wait until we have all the
commits read in and then do some computation over the whole topology;
it all has to be done incrementally.  Also, the underlying git log
sometimes gives gitk a parent commit before one of its children, and
when that happens the topology has to be modified and thus the graph
does too, if any topology that has already been drawn gets modified.

As long as the graph correctly shows the relationships between
commits, it has achieved its purpose.  If you (or anyone) can come up
with improvements that make it look nicer, that's great, and I'll
consider them as long as they don't slow down gitk on large
repositories to any noticeable extent.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A good time to pull from your gitk tree?

[Paul Mackerras]

On Mon, Mar 23, 2015 at 12:03:37PM -0700, Junio C Hamano wrote:
> 
> Is it a good time for me to pull from you, or do you recommend me to
> wait for a bit, expecting more?  We'll go in the pre-release freeze
> soon-ish, so I thought I should ping.

Now is a good time to pull from the usual place, thanks.

Regards,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] l10n: gitk/ca.po: add Catalan translation

[Paul Mackerras]

On Sun, Feb 01, 2015 at 10:53:32PM -0700, Alex Henrie wrote:
> Signed-off-by: Alex Henrie 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] gitk: po/ru.po russian translation typo fixed

[Paul Mackerras]

On Fri, Nov 14, 2014 at 05:05:28PM +0600, 0xAX wrote:
> Signed-off-by: 0xAX 
> ---
>  po/ru.po | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Remove tcl-format flag from a message that shouldn't have it

[Paul Mackerras]

On Mon, Feb 09, 2015 at 01:55:23PM -0800, Junio C Hamano wrote:
> Alex Henrie  writes:
> 
> > This is just a friendly reminder that this patch has been sitting in
> > the mailing list archives for a couple of weeks, and it has not yet
> > been accepted or commented on.
> 
> I think that is because the message was not sent to the right
> people, and also because the patch was made against a wrong project
> ;-).
> 
> I'll forward it to the gitk maintainer after digging it out of the
> archive and tweaking it.  Thanks.
> 
> Paul, comments?
> 
> -- >8 --
> From: Alex Henrie 
> Date: Thu, 22 Jan 2015 01:19:39 -0700
> Subject: gitk: Remove tcl-format flag from a message that shouldn't have it
> 
> xgettext sees "% o" and interprets it as a placeholder for an octal
> number preceded by a space. However, in this case it's not actually a
> placeholder, and most translations will replace the "% o" sequence with
> something else. Removing the tcl-format flag from this string prevents
> tools like Poedit from freaking out when "% o" doesn't appear in the
> translated string.
> 
> The corrected flag will appear in each translation's po file the next time
> the translation is updated with `make update-po`.
> 
> Signed-off-by: Alex Henrie 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Enable mouse horizontal scrolling in diff pane

[Paul Mackerras]

On Sat, Nov 15, 2014 at 03:05:06PM +0100, Gabriele Mazzotta wrote:
> Currently it's required to hold Shift and scroll up and down to move
> horizontally. Listen to Button-6 and Button-7 events too to make
> horizontal scrolling handier with touchpads and some mice.
> 
> Signed-off-by: Gabriele Mazzotta 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/3] gitk: save only changed configuration on exit

[Paul Mackerras]

On Wed, Mar 04, 2015 at 05:58:15AM +0200, Max Kirillov wrote:
> The changes:
> 
> * remove unused views_modified_names assignment
> * use if {[catch...] to check saving error
> * split error reporting from busy wait
> 
> The busy wait parameters are unchanged, mostly because I did not have time 
> yet to test them.

Thanks, applied, with some rewording of the commit messages, and I
updated the error message that is shown when a stale temporary config
file exists to what I suggested previously.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: pass --invert-grep option down to "git log"

[Paul Mackerras]

On Sun, Feb 15, 2015 at 11:29:10PM -0800, Junio C Hamano wrote:
> From: Christoph Junghans 
> Date: Mon, 12 Jan 2015 18:33:32 -0700
> 
> "git log --grep=" shows only commits with messages that
> match the given string, but sometimes it is useful to be able to
> show only commits that do *not* have certain messages (e.g. "show
> me ones that are not FIXUP commits").
> 
> Now the underlying "git log" learned the "--invert-grep" option.
> The option syntactically behaves similar to "--all-match" that
> requires that all of the grep strings to match and semantically
> behaves the opposite---it requires that none of the grep strings to
> match.
> 
> Teach "gitk" to allow users to pass it down to underlying "git log"
> command by adding it to the known_view_options array.
> 
> Signed-off-by: Christoph Junghans 
> Signed-off-by: Junio C Hamano 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] gitk: synchronize config write

[Paul Mackerras]

On Mon, Nov 10, 2014 at 12:20:02AM +0200, Max Kirillov wrote:
> If several gitk instances are closed simultaneously, safestuff procedure
> can run at the same time, resulting in a conflict which may cause losing
> of some of the instance's changes, failing the saving operation or even
> corrupting the configuration file. This can happen, for example, at user
> session closing, or at group closing of all instances of an application
> which is possible in some desktop environments.
> 
> To avoid this, make sure that only one saving operation is in progress.
> It is guarded by existance of $config_file_tmp file. Both creating the
> file and moving it to $config_file are atomic operations, so it should
> be reliable.
> 
> Reading does not need to be syncronized, because moving is atomic
> operation, and the $config_file always refers to full and correct file.
> But, if there is a stale $config_file_tmp file, report it at gitk start.
> If such file is detected at saving, just abort the saving, because this
> is how gitk used to handle errors while saving.
> 
> Signed-off-by: Max Kirillov 

The idea looks good; I have a couple of comments on the patch.  First,
50 tries over 5 seconds seems a bit excessive to me, wouldn't (say) 20
tries be enough?  Is the 50 the result of some analysis?

> + error_popup "Probably there is stale $config_file_tmp file; config 
> saving is going to fail. Check if it is being used by any existing gitk 
> process and remove it otherwise"

I would word this as "There appears to be a stale $config_file_tmp
file, which will prevent gitk from saving its configuration on exit.
Please remove it if it is not being used by any existing gitk
process."

> @@ -2811,11 +2824,16 @@ proc savestuff {w} {
>  
>  if {$stuffsaved} return
>  if {![winfo viewable .]} return
> +set remove_tmp 0
>  catch {
> - if {[file exists $config_file_tmp]} {
> - file delete -force $config_file_tmp
> + set try_count 0
> + while {[catch {set f [open $config_file_tmp {WRONLY CREAT EXCL}]}]} {
> + if {[incr try_count] > 50} {
> + error "Unable to write config file: $config_file_tmp exists"
> + }
> + after 100
>   }
> - set f [open $config_file_tmp w]
> + set remove_tmp 1
>   if {$::tcl_platform(platform) eq {windows}} {
>   file attributes $config_file_tmp -hidden true
>   }
> @@ -2878,6 +2896,14 @@ proc savestuff {w} {
>   puts $f "}"
>   close $f
>   file rename -force $config_file_tmp $config_file
> + set remove_tmp 0
> + return ""
> +} err
> +if {$err ne ""} {
> + puts "Error saving config: $err"

I would suggest checking the return from the catch statement, like
this:

if {[catch {
...
file rename -force $config_file_tmp $config_file
} err]} {
puts "Error saving config: $err"
if {$remove_tmp} {
file delete -force $config_file_tmp
}
}

rather than doing a return inside the catch.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] gitk: write only changed configuration variables

[Paul Mackerras]

On Mon, Nov 10, 2014 at 12:20:01AM +0200, Max Kirillov wrote:
> When gitk contains some changed parameter, and there is existing
> instance of gitk where the parameter is still old, it is reverted to
> that old value when the instance exits.
> 
> Instead, store a parameter in config only it is has been modified in the
> exiting instance. Otherwise, preserve the value which currently is in
> file.  This allows editing the configuration when several instances are
> running, and don't get rollback of the modification if some other
> instance where the configuration was not edited is closed last.
> 
> For scalar variables, use trace(3tcl) to detect their change. Since `trace` 
> can
> send bogus events, doublecheck if the value has really been changed, but once
> it is marked as changed, do not reset it back to unchanged ever, because if
> user has restored the original value, it's the decision which should be stored
> as well as modified value.
> 
> Treat view list especially: instead of rewriting the whole list, merge
> individual views. Place old and updated views at their older placed, add
> new ones to the end of list. Collect modified view explicitly, in newviewok{}
> and delview{}.
> 
> Do not merge geometry values. They are almost always changing because
> user moves and resises windows, and there is no way to find which one of
> the geometries is most desired. Just overwrite them unconditionally,
> like earlier.
> 
> Signed-off-by: Max Kirillov 

Looks pretty nice; I just have one comment:

> + lappend views_modified_names $current_viewname($v)

This view_modified_names variable doesn't seem to be used anywhere.
If you don't mind me taking out this line, I'll do that and apply the
patch.

Regards,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] gitk: write only changed configuration variables

[Paul Mackerras]

On Sun, Sep 14, 2014 at 11:35:58PM +0300, Max Kirillov wrote:
> When gitk contains some changed parameter, and there is existing
> instance of gitk where the parameter is still old, it is reverted to
> that old value when the instance exits.
> 
> Instead, store a parameter in config only it is has been modified in the
> exiting instance. Otherwise, preserve the value which currently is in
> file.  This allows editing the configuration when several instances are
> running, and don't get rollback of the modification if some other
> instance where the configuration was not edited is closed last.
> 
> Since trace(3tcl) can send bogus events, doublecheck if the value has
> really been changed, but once it is marked as changed, do not reset it
> back to unchanged ever, because if user has restored the original value,
> it's the decision which should be stored as well as modified value.
> 
> Treat view list especially: instead of rewriting the whole list, merge
> individual views. Place old and updated views at their older placed, add
> new ones to the end of list.
> 
> Do not merge geometry values. They are almost always changing because
> user moves and resises windows, and there is no way to find which one of
> the geometries is most desired. Just overwrite them unconditionally,
> like earlier.
> 
> Signed-off-by: Max Kirillov 

I like the idea here but the implementation seems a bit more
complicated than it needs to be.  It seems to me that we need the
trace only for the non-array configuration variables; the array case
is only for the view definitions, and I think we could just set the
changed flag for a view explicitly in [newviewok].  That would
simplify things quite a bit.

I'm also not convinced we need all the uses of upvar.  Why do we need
to use upvar to rename viewname, viewfiles etc. to current_viewname,
etc.?  If you're concerned about what might possibly be in the .gitk
when you source it, perhaps doing the source inside a namespace would
be a cleaner approach?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] gitk refactor: remove boilerplate for configuration variables

[Paul Mackerras]

On Sun, Sep 14, 2014 at 11:35:57PM +0300, Max Kirillov wrote:
> Signed-off-by: Max Kirillov 

This is a nice simplification, applied, thanks.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: catch mkdtemp errors

[Paul Mackerras]

On Wed, Jun 18, 2014 at 07:53:14PM -0700, David Aguilar wrote:
> 105b5d3fbb1c00bb0aeaf9d3e0fbe26a7b1993fc introduced a dependency
> on mkdtemp, which is not available on Windows.
> 
> Use the original temporary directory behavior when mkdtemp fails.
> This makes the code use mkdtemp when available and gracefully
> fallback to the existing behavior when it is not available.
> 
> Helped-by: Junio C Hamano 
> Helped-by: brian m. carlson 
> Signed-off-by: David Aguilar 

Thanks, applied (with slight modification to commit message).

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: catch mkdtemp errors

[Paul Mackerras]

On Thu, Jun 26, 2014 at 01:47:36PM -0700, Junio C Hamano wrote:
> David Aguilar  writes:
> 
> > 105b5d3fbb1c00bb0aeaf9d3e0fbe26a7b1993fc introduced a dependency
> > on mkdtemp, which is not available on Windows.
> >
> > Use the original temporary directory behavior when mkdtemp fails.
> > This makes the code use mkdtemp when available and gracefully
> > fallback to the existing behavior when it is not available.
> >
> > Helped-by: Junio C Hamano 
> > Helped-by: brian m. carlson 
> > Signed-off-by: David Aguilar 
> > ---
> 
> In the meantime, I've fetched from you and merged up to your
> master~2 aka 17f9836c (gitk: Show staged submodules regardless of
> ignore config, 2014-04-08).

I have applied and pushed out this patch, along with one from Max
Kirillov, so please do another fetch.

Thanks,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: use mktemp -d to avoid predictable temporary directories

[Paul Mackerras]

On Fri, Jun 13, 2014 at 02:43:48PM -0700, David Aguilar wrote:
> gitk uses a predictable ".gitk-tmp.$PID" pattern when generating
> a temporary directory.
> 
> Use "mktemp -d .gitk-tmp.XX" to harden gitk against someone
> seeding /tmp with files matching the pid pattern.
> 
> Signed-off-by: David Aguilar 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: honor TMPDIR when viewing external diffs

[Paul Mackerras]

On Fri, Jun 13, 2014 at 02:13:37PM -0700, David Aguilar wrote:
> gitk fails to show diffs when browsing a read-only repository.
> This is due to gitk's assumption that the current directory is always
> writable.
> 
> Teach gitk to honor either the GITK_TMPDIR or TMPDIR environment
> variables.  This allows users to override the default location
> used when writing temporary files.
> 
> Signed-off-by: David Aguilar 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Allow displaying time zones from author and commit timestamps

[Paul Mackerras]

On Mon, May 12, 2014 at 07:25:58AM -0400, Anders Kaseorg wrote:
> Now gitk can be configured to display author and commit dates in their
> original timezone, by putting %z into datetimeformat in ~/.gitk.
> 
> Signed-off-by: Anders Kaseorg 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: show staged submodules regardless of ignore config

[Paul Mackerras]

On Fri, Jun 06, 2014 at 02:08:29PM -0700, Junio C Hamano wrote:
> From: Jens Lehmann 
> Date: Tue, 8 Apr 2014 21:36:08 +0200
> 
> Currently setting submodule..ignore and/or diff.ignoreSubmodules to
> "all" suppresses all output of submodule changes for gitk. This is really
> confusing, as even when the user chooses to record a new commit for an
> ignored submodule by adding it manually this change won't show up under
> "Local changes checked in to index but not committed".
> 
> Fix that by using the '--ignore-submodules=dirty' option for both callers
> of "git diff-index --cached" when the underlying git version supports that
> option.
> 
> Signed-off-by: Jens Lehmann 
> Signed-off-by: Junio C Hamano 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: switch to patch mode when searching for line origin

[Paul Mackerras]

On Sat, Apr 05, 2014 at 11:38:50PM +0300, Max Kirillov wrote:
> If the "Show origin of this line" is started from tree mode,
> it still shows the result in tree mode, which I suppose not
> what user expects to see.

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: replace SHA1 entry field on keyboard paste

[Paul Mackerras]

On Thu, Mar 20, 2014 at 01:58:51AM -0700, Ilya Bobyr wrote:
> We already replace old SHA with the clipboard content for the mouse
> paste event.  It seems reasonable to do the same when pasting from
> keyboard.
> 
> Signed-off-by: Ilya Bobyr 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Paul Mackerras]

On Wed, Jan 22, 2014 at 12:18:27PM -0800, Junio C Hamano wrote:
> Is this a good time for me to pull from you?  I see these on your
> 'master' branch.
> 
> 8f86339 gitk: Comply with XDG base directory specification
> 786f15c gitk: Replace "next" and "prev" buttons with down and up arrows
> c61f3a9 gitk: chmod +x po2msg.sh
> 6c626a0 gitk: Update copyright dates
> 45f884c gitk: Add Bulgarian translation (304t)
> 1f3c872 gitk: Fix mistype
> 
> Thanks.

Yes, please pull.  I have just pushed one more:

76d64ca gitk: Indent word-wrapped lines in commit display header

Thanks,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] gitk: Comply with XDG base directory specification

[Paul Mackerras]

On Tue, Jan 21, 2014 at 07:10:16PM +, Astril Hayato wrote:
> Write the gitk config data to $XDG_CONFIG_HOME/git/gitk 
> ($HOME/.config/git/gitk
> by default) in line with the XDG specification. This makes it consistent with
> git which also follows the spec.
> 
> If $HOME/.gitk already exists use that for backward compatibility, so only new
> installations are affected.
> 
> Signed-off-by: Astril Hayato 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Paul Mackerras]

On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote:
> On 13-12-18 11:04 AM, Marc Branchaud wrote:
> > Users often find that "next" and "prev" do the opposite of what they
> > expect.  For example, "next" moves to the next match down the list, but
> > that is almost always backwards in time.  Replacing the text with arrows
> > makes it clear where the buttons will take the user.
> 
> Any opinions on this, either way?
> 
> I've grown fond of the down/up arrows.  I find them much clearer than the
> current next/prev buttons.
> 
> My only niggle about this patch is that the buttons are much smaller,
> requiring a bit more precision clicking.  But the smaller buttons allow more
> room for other widgets.

I showed it to a few colleagues who use gitk a lot.  One was
indifferent, the others liked it, so I have applied it.

Thanks,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: chmod +x po2msg

[Paul Mackerras]

On Mon, Dec 02, 2013 at 11:12:43AM -0800, Junio C Hamano wrote:
> From: Jonathan Nieder 
> Date: Mon, 25 Nov 2013 13:00:10 -0800
> 
> The Makefile only runs it using tclsh, but because the fallback po2msg
> script has the usual tcl preamble starting with #!/bin/sh it can also
> be run directly.
> 
> Signed-off-by: Jonathan Nieder 
> Signed-off-by: Junio C Hamano 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk i18n: Added Bulgarian translation (304t)

[Paul Mackerras]

On Wed, Jan 15, 2014 at 01:27:29PM +0200, al_sho...@yahoo.com wrote:
> From: Alexander Shopov 
> 
> Signed-off-by: Alexander Shopov 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Comply with XDG base directory specification

[Paul Mackerras]

On Fri, Dec 13, 2013 at 07:46:36PM +, Astril Hayato wrote:
> Write the gitk config data to $XDG_CONFIG_HOME/git/gitk 
> ($HOME/.config/git/gitk
> by default) in line with the XDG specification. This makes it consistent with
> git which also follows the spec.
> 
> If $HOME/.gitk already exists use that for backward compatibility, so only new
> installations are affected.

Sounds reasonable...

> @@ -12058,7 +12061,27 @@ namespace import ::msgcat::mc
>  ## And eventually load the actual message catalog
>  ::msgcat::mcload $gitk_msgsdir
>  
> -catch {source ~/.gitk}
> +catch {
> +# follow the XDG base directory specification by default. See
> +# http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> +if {[info exists env(XDG_CONFIG_HOME)] && $env(XDG_CONFIG_HOME) ne ""} {
> + # XDG_CONFIG_HOME environment variable is set
> + set config_file [file join $env(XDG_CONFIG_HOME) git gitk]
> + set config_file_tmp [file join $env(XDG_CONFIG_HOME) git gitk-tmp]
> +} else {
> + # default XDG_CONFIG_HOME
> + set config_file "~/.config/git/gitk"
> + set config_file_tmp "~/.config/git/gitk-tmp"
> +}
> +if {![file exists $config_file]} {
> + if {![file exists [file dirname $config_file]]} {
> + file mkdir [file dirname $config_file]
> + }
> + # for backward compatability use the old config file if it exists
> + if {[file exists "~/.gitk"]} {set config_file "~/.gitk"}

Don't we need to set config_file_tmp here too?

And, do we really want to create the ~/.config/git directory if we are
using the old-style ~/.gitk as the config file?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: fix mistype

[Paul Mackerras]

On Sat, Jan 18, 2014 at 02:58:51PM +0200, Max Kirillov wrote:
> Signed-off-by: Max Kirillov 

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 gitk 0/5] gitk -L

[Paul Mackerras]

On Sat, Nov 16, 2013 at 06:37:39PM +0100, Thomas Rast wrote:
> These patches implement 'gitk -L'.  They are exactly the same as the
> gitk patches from v2 at
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/227151/focus=236903
> 
> except that they apply to the gitk-git tree at
> 
>   git://ozlabs.org/~paulus/gitk

Thanks; applied all 5 (with s/sticked/stuck/g in patch 5).

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] gitk: make pointer selection visible in highlighted lines

[Paul Mackerras]

On Thu, Nov 28, 2013 at 11:20:18PM +0200, Max Kirillov wrote:
> Custom tags have higher priority than `sel`, and when they define their
> own background, it makes selection invisible. Especially inconvenient
> for `filesep` (to select filenames), but also affects other tags.
> Use `tag raise` to fix `sel`'s priority.
> 
> Also change `omark` tag handling, so that it is created once, together
> with others, and then only removed from text rather than deleted. Then
> it will not get larger priority than the `sel` tag.

This conflicts with the recent change to highlight the current search
hit in orange (c46149, "gitk: Highlight current search hit in
orange").  With the selection being the highest-priority tag, the
current search hit gets shown in grey instead.  I think I prefer the
orange.  I agree though that if the user explicitly selects part of
the text using the mouse, the selection highlight should be the
highest priority in that case.  Maybe the solution is to not select
the search hit automatically?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history

[Paul Mackerras]

On Wed, Oct 30, 2013 at 01:47:08PM +0100, Nicolas Cornu wrote:
> This is useful on all our repos, every times, as we put a tag per day.
> If the HEAD didn't move during 150 days, we got 150 tags.

Here is a patch that I did some time ago but have never pushed out.
Do you think it is an improvement when using gitk on a repo with lots
of tags?

Paul.

[PATCH] gitk: Tag display improvements

When a commit has many tags, the tag icons in the graph display can
easily become so wide as to push the commit message off the right-hand
edge of the graph display pane.  This changes the display so that if
there are more than 3 tags or they would take up more than a quarter
of the width of the pane, we instead display a single tag icon with
a legend inside it like "4 tags...".  If the user clicks on the tag
icon, gitk then displays all the tags in the diff display pane.

Signed-off-by: Paul Mackerras 
---
 gitk | 96 ++--
 1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/gitk b/gitk
index 5cd00d8..0bdb146 100755
--- a/gitk
+++ b/gitk
@@ -2385,6 +2385,7 @@ proc makewindow {} {
 $ctext tag conf found -back $foundbgcolor
 $ctext tag conf currentsearchhit -back $currentsearchhitbgcolor
 $ctext tag conf wwrap -wrap word
+$ctext tag conf bold -font textfontbold
 
 .pwbottom add .bleft
 if {!$use_ttk} {
@@ -6387,6 +6388,25 @@ proc bindline {t id} {
 $canv bind $t  "lineclick %x %y $id 1"
 }
 
+proc graph_pane_width {} {
+global use_ttk
+
+if {$use_ttk} {
+   set g [.tf.histframe.pwclist sashpos 0]
+} else {
+   set g [.tf.histframe.pwclist sash coord 0]
+}
+return [lindex $g 0]
+}
+
+proc totalwidth {l font extra} {
+set tot 0
+foreach str $l {
+   set tot [expr {$tot + [font measure $font $str] + $extra}]
+}
+return $tot
+}
+
 proc drawtags {id x xt y1} {
 global idtags idheads idotherrefs mainhead
 global linespc lthickness
@@ -6398,9 +6418,27 @@ proc drawtags {id x xt y1} {
 set marks {}
 set ntags 0
 set nheads 0
+set singletag 0
+set maxtags 3
+set maxtagpct 25
+set maxwidth [expr {[graph_pane_width] * $maxtagpct / 100}]
+set delta [expr {int(0.5 * ($linespc - $lthickness))}]
+set extra [expr {$delta + $lthickness + $linespc}]
+
 if {[info exists idtags($id)]} {
set marks $idtags($id)
set ntags [llength $marks]
+   if {$ntags > $maxtags ||
+   [totalwidth $marks mainfont $extra] > $maxwidth} {
+   # show just a single "n tags..." tag
+   set singletag 1
+   if {$ntags == 1} {
+   set marks [list "tag..."]
+   } else {
+   set marks [list [format "%d tags..." $ntags]]
+   }
+   set ntags 1
+   }
 }
 if {[info exists idheads($id)]} {
set marks [concat $marks $idheads($id)]
@@ -6413,7 +6451,6 @@ proc drawtags {id x xt y1} {
return $xt
 }
 
-set delta [expr {int(0.5 * ($linespc - $lthickness))}]
 set yt [expr {$y1 - 0.5 * $linespc}]
 set yb [expr {$yt + $linespc - 1}]
 set xvals {}
@@ -6428,7 +6465,7 @@ proc drawtags {id x xt y1} {
}
lappend xvals $xt
lappend wvals $wid
-   set xt [expr {$xt + $delta + $wid + $lthickness + $linespc}]
+   set xt [expr {$xt + $wid + $extra}]
 }
 set t [$canv create line $x $y1 [lindex $xvals end] $y1 \
   -width $lthickness -fill $reflinecolor -tags tag.$id]
@@ -6444,7 +6481,12 @@ proc drawtags {id x xt y1} {
   $xr $yt $xr $yb $xl $yb $x [expr {$yb - $delta}] \
   -width 1 -outline $tagoutlinecolor -fill $tagbgcolor \
   -tags tag.$id]
-   $canv bind $t <1> [list showtag $tag_quoted 1]
+   if {$singletag} {
+   set tagclick [list showtags $id 1]
+   } else {
+   set tagclick [list showtag $tag_quoted 1]
+   }
+   $canv bind $t <1> $tagclick
set rowtextx([rowofcommit $id]) [expr {$xr + $linespc}]
} else {
# draw a head or other ref
@@ -6471,7 +6513,7 @@ proc drawtags {id x xt y1} {
set t [$canv create text $xl $y1 -anchor w -text $tag -fill 
$headfgcolor \
   -font $font -tags [list tag.$id text]]
if {$ntags >= 0} {
-   $canv bind $t <1> [list showtag $tag_quoted 1]
+   $canv bind $t <1> $tagclick
} elseif {$nheads >= 0} {
$canv bind $t $ctxbut [list headmenu %X %Y $id $tag_quoted]
}
@@ -10878,6 +10920,23 @@ proc listrefs {id} {
 return [list $x $y $z]
 }
 
+proc add_tag_ctext {tag} {
+global ctext cached_tagcontent tagids
+
+if {![info exists cached_tagcontent($tag)]} {
+   catch {
+   set cached_tagcontent($tag) [exec git cat-file -p $tag]
+   

Re: [PATCH gitk 0/4] gitk support for git log -L

[Paul Mackerras]

Hi Thomas,

On Wed, Jul 31, 2013 at 03:17:41PM +0200, Thomas Rast wrote:
> Jens Lehmann  writes:
> 
> > Am 29.07.2013 21:37, schrieb Thomas Rast:
> >> Thomas Rast  writes:
> >> 
> >>> Thomas Rast  writes:
> >>>
>  Now that git log -L has hit master, I figure it's time to discuss the
>  corresponding change to gitk.
> >>>
> >>> Paul, any news on this?  Any chance we can get it into the next release,
> >>> since that will also be the first release to ship with 'git log -L'?
> >> 
> >> Jens pointed out privately that the handling of unstuck -L options is
> >> unfortunate, to put it mildly.  I'll send a reroll.
> >
> > But as soon as that is fixed I'd really like to see this applied, as
> > I think gitk is the perfect tool to show history information.

One thing I worry about is having gitk storing in memory not just the
history graph but also all the diffs (assuming I have understood
correctly what you're doing).  Gitk's memory consumption is already
pretty large.  However, I can't see an alternative at this point.

> Unfortunately it's turning out to be harder than I hoped.  gitk runs the
> arguments through git-rev-parse, which only knows that -n gets an
> unstuck argument.  Consequently, gitk accepts an unstuck -n but only
> stuck forms of -S and -G.

Excuse my ignorance, but what do you mean by "stuck" vs. "unstuck"?

Thanks,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please pull one more gitk commit

[Paul Mackerras]

Junio,

If there is still time to get stuff in for 1.8.3, please pull my
gitk repository from the usual place to get the update to the
Swedish translations that I just received from Peter Krefting.

Thanks,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Update Swedish translation (304t)

[Paul Mackerras]

On Thu, May 16, 2013 at 08:16:30AM +0100, Peter Krefting wrote:
> The patch is attached gzipped to avoid character encoding issues.

Thanks, applied.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: simplify file filtering

[Paul Mackerras]

On Mon, May 13, 2013 at 10:58:49AM +0200, Stefan Haller wrote:
> 
> Would you also consider Tair Sabirgaliev's v2 patch for not launching
> gitk in the background on Mac? This fixes a very serious usability
> problem.
> 
>   

Yes, I put it in.  I didn't see it when he posted because my spam
filters decided it was spam. :)

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: simplify file filtering

[Paul Mackerras]

On Sun, May 12, 2013 at 03:54:14PM -0700, Junio C Hamano wrote:
> 
> Thanks; is this the last one for this cycle and is your usual branch
> ready to be pulled?

It is now; please pull from the usual place,
git://ozlabs.org/~paulus/gitk.git.

Thanks,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: simplify file filtering

[Paul Mackerras]

On Sun, May 12, 2013 at 03:54:14PM -0700, Junio C Hamano wrote:
> Paul Mackerras  writes:
> 
> > On Sat, Apr 27, 2013 at 05:01:39PM -0500, Felipe Contreras wrote:
> >> git diff is perfectly able to do this with '-- files', no need for
> >> manual filtering.
> >> 
> >> Signed-off-by: Felipe Contreras 
> >
> > Thanks, applied, with the commit message expanded to say that this
> > makes gettreediffs do the same as getblobdiffs.
> >
> > Paul.
> 
> Thanks; is this the last one for this cycle and is your usual branch
> ready to be pulled?

I'm still deciding whether to put in Martin Langhoff's patch with a
modified label ("changing lines matching" rather than "with changes
matching regex").  I'm leaning towards it but was waiting a little to
see if anyone had comments on the wording.  I'll decide by the end of
today and send you a pull request either way.

Thanks,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: simplify file filtering

[Paul Mackerras]

On Sat, Apr 27, 2013 at 05:01:39PM -0500, Felipe Contreras wrote:
> git diff is perfectly able to do this with '-- files', no need for
> manual filtering.
> 
> Signed-off-by: Felipe Contreras 

Thanks, applied, with the commit message expanded to say that this
makes gettreediffs do the same as getblobdiffs.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Add menu item for reverting commits

[Paul Mackerras]

On Sat, Apr 27, 2013 at 04:36:13PM +0200, Knut Franke wrote:
> Sometimes it's helpful (at least psychologically) to have this feature
> easily accessible. Code borrows heavily from cherrypick.
> 
> Signed-off-by: Knut Franke 

Thanks, applied, after undoing the linewrapping (done by your mailer?).

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: add support for -G'regex' pickaxe variant

[Paul Mackerras]

On Fri, May 10, 2013 at 11:13:22PM -0700, Jonathan Nieder wrote:
> Paul Mackerras wrote:
> 
> > I thought I had replied to this patch; maybe I only thought about it.
> >
> > Given that we already have a selector to choose between exact and
> > regexp matching, it seems more natural to use that rather than add a
> > new selector entry.  Arguably the "IgnCase" option should be disabled
> > when "adding/removing string" is selected.
> 
> Thanks.  I think I disagree: "log -G" and "log -S" are different
> operations, not variations on the same one.  

OK, fair enough, and I see there is in fact a --pickaxe-regex we
could use.

> The description "Find next commit adding/removing string:" very
> clearly conveys what "-S" means.  Maybe -G would be more clearly
> described as "Find next commit changing line that matches regex:" or
> "Find next commit changing line containing:"?

How about "changing lines matching:"?  If it gets too long it will
take up too much horizontal room.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: add support for -G'regex' pickaxe variant

[Paul Mackerras]

On Tue, May 07, 2013 at 01:17:18PM -0400, Martin Langhoff wrote:
> I just did git rebase origin/master for the umpteenth time, which
> reminded me this nice patch is still pending.
> 
> ping?

I thought I had replied to this patch; maybe I only thought about it.

Given that we already have a selector to choose between exact and
regexp matching, it seems more natural to use that rather than add a
new selector entry.  Arguably the "IgnCase" option should be disabled
when "adding/removing string" is selected.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: workaround Tcl/Tk Cmd-TAB behavior on OSX

[Paul Mackerras]

On Thu, Apr 11, 2013 at 01:02:48AM +0600, Tair Sabirgaliev wrote:
> On OSX Tcl/Tk application windows are created behind all
> the applications down the stack of windows. This is very
> annoying, because once a gitk window appears, it's the
> downmost window and switching to it is pain.
> 
> The patch is trivial: if we are on OSX, emulate Cmd-Shift-TAB
> key event, so that the gitk application window is brought
> from bottom to top.
> 
> Signed-off-by: Tair Sabirgaliev 
> ---
>  gitk | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/gitk b/gitk
> index 572f73f..60a87fc 100755
> --- a/gitk
> +++ b/gitk
> @@ -11687,6 +11687,19 @@ if {[catch {package require Tk 8.4} err]} {
>  exit 1
>  }
>  +# On OSX workaround the Tcl/Tk windows going down the stack of Cmd-TAB
> +if {[tk windowingsystem] eq "aqua"} {
> +exec osascript -e {
> +tell application "System Events"
> +key down command
> +key down shift
> +keystroke tab
> +key up shift
> +key up command
> +end tell+}
> +}

Is this really the only way to do it?  It seems a bit hacky to me.  I
would think you should be able to use the "wm" command to achieve what
you want.  I don't use Mac OS, so I don't know exactly how Tcl/Tk
behaves on it, but this page looks like it might hold some clues for
what you want to do:

http://teapot.activestate.com/package/name/windowlist/ver/1.4/arch/tcl/file.tm

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitk: Display the date of a tag in a human friendly way.

[Paul Mackerras]

On Sun, Feb 03, 2013 at 06:37:42PM +, Anand Kumria wrote:
> Hi Pau,
> 
> I've not been able to find the canonical location of your gitk repository.
> 
> I've tried kernel.org, samba.org and ozlabs.org; none of them to have
> it - nor does any amount of google searching I do reveal the location.
> 
> I realise you've probably had a busy month with linux.conf.au but it
> would be nice to have some feedback.
> 
> Could you let me know where gitk is hosted and I'll re-roll this patch
> against that (and update the docs so others don't need to go hunting).

It's at git://ozlabs.org/~paulus/gitk.git

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch] gitk: added a file history browser

[Paul Mackerras]

On Wed, Feb 20, 2013 at 12:14:20AM +0100, Dirk wrote:
> Hi,
> 
> I added a file history browser for a single file in the gitk. I use git log 
> with the option --follow. This option is useful for the user switch from cvs 
> to git. He misses a history from only one file and the function "Highlight 
> this only" breaks by moved files. The new option do not break by the moved 
> files. I use ideas from the tkcvs branch dialog.

How is this better than running "gitk --follow -- file"?

Also, it's rather a large patch with only a two-line patch description,
which is not really adequate.  And it's missing a Signed-off-by.

I think the right way to do this is to have the file menu option
create a new view specifying the file and the --follow option,
rather than creating a whole new window.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html