[PATCH] gitk: different color for boundary commits

[PATCH] gitk: different color for boundary commits

[Stefan Dotterweich]

When using filters, the commit list shows not only commits matching
the filter criteria, but also boundary commits. When going through a
list of say, all commits changing the variable `foo`, often half of
the displayed commits are boundary commits. In this case the boundary
commits are of little interest.

However, there is no way to hide them or quickly distinguish them from
the actual commits.  Boundary commits can be identified by the white
color inside the circle, but that is not easily recognisable.  On each
line you  have to look at the circle color to identify the commit
type. This makes it hard to just quickly skim a list of commits,
especially when looking at dates and authors which are further to the
right.

Therefore, to make boundary commits easier to recognise, display their
text in a different color.

Signed-off-by: Stefan Dotterweich <stefandotterweich@gmx.de>
---
 I made this change for myself, but it would be nice to see it in the
 official build.

 gitk-git/gitk | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index a14d7a16b..8f5e0df75 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -6115,7 +6115,7 @@ proc drawcmittext {id row col} {
     global canvxmax boldids boldnameids fgcolor markedid
     global mainheadid nullid nullid2 circleitem circlecolors ctxbut
     global mainheadcirclecolor workingfilescirclecolor indexcirclecolor
-    global circleoutlinecolor
+    global circleoutlinecolor uifgdisabledcolor
 
     # listed is 0 for boundary, 1 for normal, 2 for negative, 3 for left, 4 for right
     set listed $cmitlisted($curview,$id)
@@ -6128,6 +6128,10 @@ proc drawcmittext {id row col} {
     } else {
 	set ofill [lindex $circlecolors $listed]
     }
+    set textcolor $fgcolor
+    if {$listed eq 0} {
+	set textcolor $uifgdisabledcolor
+    }
     set x [xc $row $col]
     set y [yc $row]
     set orad [expr {$linespc / 3}]
@@ -6189,12 +6193,12 @@ proc drawcmittext {id row col} {
 	    set nfont mainfontbold
 	}
     }
-    set linehtag($id) [$canv create text $xt $y -anchor w -fill $fgcolor \
+    set linehtag($id) [$canv create text $xt $y -anchor w -fill $textcolor \
 			   -text $headline -font $font -tags text]
     $canv bind $linehtag($id) $ctxbut "rowmenu %X %Y $id"
-    set linentag($id) [$canv2 create text 3 $y -anchor w -fill $fgcolor \
+    set linentag($id) [$canv2 create text 3 $y -anchor w -fill $textcolor \
 			   -text $name -font $nfont -tags text]
-    set linedtag($id) [$canv3 create text 3 $y -anchor w -fill $fgcolor \
+    set linedtag($id) [$canv3 create text 3 $y -anchor w -fill $textcolor \
 			   -text $date -font mainfont -tags text]
     if {$selectedline == $row} {
 	make_secsel $id
-- 
2.12.0

Re: [PATCH] gitk: different color for boundary commits

[Stefan Haller]

Stefan Dotterweich <stefandotterweich@gmx.de> wrote:

> When using filters, the commit list shows not only commits matching
> the filter criteria, but also boundary commits. When going through a
> list of say, all commits changing the variable `foo`, often half of
> the displayed commits are boundary commits. In this case the boundary
> commits are of little interest.
> 
> However, there is no way to hide them or quickly distinguish them from
> the actual commits.  Boundary commits can be identified by the white
> color inside the circle, but that is not easily recognisable.  On each
> line you  have to look at the circle color to identify the commit
> type. This makes it hard to just quickly skim a list of commits,
> especially when looking at dates and authors which are further to the
> right.
> 
> Therefore, to make boundary commits easier to recognise, display their
> text in a different color.

I would like to go one step further and not show the boundary commits at
all. Why do we need them again? (I think this has been discussed before,
but I can't find it right now. The only reference I could find is this
thread: <https://public-inbox.org/git/571F6852.1070405@qt.io/T/#u>,
which doesn't explain *why* gitk shows the boundary commits in the first
place.)

In my opinion, when saying "gitk --author=foo", the list of commits in
the top pane should look the same as the ouput of 
"git log --oneline --author=foo".


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/