Re: gitk changing line color for no reason after merge

From: Pavel Roskin <proski@gnu.org>
Date: Feb 7, 2006, 05:18 UTC
Message-ID: <1139289517.15955.23.camel@dv>
In-Reply-To: <1138900897.28967.18.camel@dv>

Hello!

Sorry for replying to myself, but there is nobody else to reply to.

> I think it would be much better if line colors only change at
> non-trivial nodes, i.e. those with more than one child or parent.

I didn't realize that the colors correspond to nodes, not branches. Every node has one color that is used for lines to all of its children. It would be much better to assign colors to "branches" consisting of individual lines connecting nodes, but changing that would require many changes in gitk.

Show 15 quoted lines

> diff --git a/gitk b/gitk
> index f12b3ce..14ff570 100755
> --- a/gitk
> +++ b/gitk
> @@ -770,7 +770,7 @@ proc assigncolor {id} {
>  
>      if [info exists colormap($id)] return
>      set ncolors [llength $colors]
> -    if {$nparents($id) <= 1 && $nchildren($id) == 1} {
> +    if {$nchildren($id) == 1} {
>  	set child [lindex $children($id) 0]
>  	if {[info exists colormap($child)]
>  	    && $nparents($child) == 1} {
> 
>

I still stand behind this patch because it eliminates color changes on the nodes that have exactly one child and parent. $nparents($id) is irrelevant here, because it characterizes the current node, but the code decides whether the line should change color at the child node.

However, further changes to reduce color changes didn't produce nice results for me. If I try to keep one color running as long as possible, I get branches of the same color because, as I said, gitk uses the same color for connections to all children. So, every node on the branch spurs branching lines of the same color, which can intersect or run side-by-side.

I can submit this patch formally, but I hope to get some comments first.

-- 
Regards,
Pavel Roskin