Re: gitk changing line color for no reason after merge

[Pavel Roskin <proski@gnu.org>]

On Tue, 2006-02-07 at 19:56 +1100, Paul Mackerras wrote:
> Pavel Roskin writes:
> > Hello!
> 
> > 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
> 
> Why would that be better?

Because you would get consistent colors between line forks.  The color
would help to tack the line.  Anyway, I don't think I'll ever implement
it myself.

> > > -    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
> 
> Ummm... I don't see that you have changed anything for nodes that have
> exactly one parent?

Nodes with one parent are fine.  It's nodes with multiple parents that
are the problem - they fail to inherit the color assigned to their
child.

Let's see what assigncolor does:

|  ----------- color assigned to the child, possibly to be inherited
|
child
|
|  ----------- we are assigning color to this line
|
id ----------- we are processing this node
|\
| \--------\
|           |
parent1   parent2

Why should color at the child change because its single parent has
several parents?

> > 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.
> 
> The colors are really just to make the lines visually distinct.  They
> (the colors) have no semantic meaning.  (I did try coloring the lines
> according to the committer, but I just ended up with an awful lot of
> lines being the same color - corresponding to one Linus Torvalds. :)

I guess I wasn't clear about my intentions.  My only intention is
exactly that - "to make the lines visually distinct".  There is one
corner case where the color changes for no reason.  There are cases that
are harder to fix, but this one is easy, and I have found a working
solution.

-- 
Regards,
Pavel Roskin