From: Paul Mackerras Date: Tue, 07 Feb 2006 08:56:48 GMT Subject: Re: gitk changing line color for no reason after merge Message-ID: <17384.24784.898327.669875@cargo.ozlabs.ibm.com> In-Reply-To: <1139289517.15955.23.camel@dv> 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? > > - 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? > 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. :) Paul.