Re: gitk changing line color for no reason after merge

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.

> 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

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