Re: gitk changing line color for no reason after merge
- From
- Pavel Roskin <proski@gnu.org>
- Date
- Feb 8, 2006, 01:10 UTC
- Message-ID
- <1139361014.13646.37.camel@dv>
- In-Reply-To
- <17384.24784.898327.669875@cargo.ozlabs.ibm.com>
On Tue, 2006-02-07 at 19:56 +1100, Paul Mackerras wrote:
Show 9 quoted lines
> 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.
Show 13 quoted lines
> > > - 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?
Show 11 quoted lines
> > 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