Re: gitk changing line color for no reason after merge

From: Junio C Hamano <junkio@cox.net>
Date: Feb 7, 2006, 10:04 UTC
Message-ID: <7vlkwnxz5t.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1139289517.15955.23.camel@dv>

Pavel Roskin <proski@gnu.org> writes:

> 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.

It all depends on what you are trying to achieve with colours. Being a bit colour-challenged, I am not in a good position to comment on how much gitk's use of different colours is helping the readability, but I suspect not very much. Use of too many colours just makes things distracting. Especially weaker colours like light yellow are very hard to see on a white background, at least to me.

Trying to differenciate "trunk" with "side branches" may be sometimes useful in a small one-man project, but it quickly breaks down once you start merging from all over the place, since merges in distributed development do not have inherent distinction between "trunk" and "side branches".

One thing it _could_ do is to assign different colours to edges coming into a merge node, and match the colour of the edge that leads to a parent to the colour in which the diff text from that parent is shown. Then the colouring becomes somewhat meaningful.

Maybe gitk is already doing it, but it makes me suspect it doesn't, to read the way the code initialises "$ctext tag conf m$N" and uses the m$N tag for each diff output line, which is done pretty much independently from the procedure that paint edges (the one you touch in your patch).