Based on a /chat discussion with Martin Gagnon:

The automatic branch colors are sometimes so close that they're difficult to distinguish. A timely example of this can be seen at:

https://sqlite.org/src/timeline?c=85fe9c6155f72583&skin=eagle&once

Ideas on how to improve upon that are failing me, given how the timeline is rendered: we don't(?) know all of the colors in advance, AFAIK, so cannot(?) filter/modify that list before rendering the timeline. If we knew all relevant colors in advance, we could go through them and tweak any which are "too close".

Maybe we can keep track of them incrementally and adjust the next color appropriately if there's too close of a match in the list of already-seen colors.

We can't retroactively change the colors as collisions are encountered because by the time one is encountered, older HTML elements have already been emitted.

What if...

(Just spitballing...)

Instead of adding bgcolor attributes to the affected elements, we instead add a CSS class to each named branch-color-NNN, where NNN is a number in the range (say) 1..20. The timeline view could keep track of how many branches it's rendered so far and always assign the Nth branch-color-NNN CSS class to the Nth branch. When we have more than (say) 20 branches, it loops around the color chart and starts anew.

We could pre-define those (say) 20 colors in CSS for both light- and dark-themed skins.

This would guaranty no collisions so long as there are fewer than (say) 20 branches shown at once, and would reduce collisions to 1/20th when many branches are shown.

The down-side would be that the colors of each branch could change on each visit, which may cause some confusion.

Other ideas for how to improve this would be welcomed.

I like that the chosen color is stable for a given branch. Maybe something else could be done.

I don't know, looks a bit crazy. Maybe it can be tweaked. This is:

style="background:linear-gradient(0deg, #edc9f1, #f8f6cf)"

Maybe it can be tweaked to look better? I dunno.

But the advantage would be: as two colors are chosen from the hash (which should be possible), the number of combinations is the square of the current number of choices. Which should make collisions quite a bit more unlikely.

linear-gradient() was rolled out in CSS of browsers in 2012 and 2013, only Edge got it only 2015. I think that is around long enough that most users should have browser-support.

Just an idea.

...

I assume char *hash_color(const char *z) in color.c calculates the color?

EDIT: The radial-gradient() and the repeating variants to both were introduced at the same time:

style="background:repeating-linear-gradient(to right, #cbf0e8 0, #f2ceca 10px, #cbf0e8 20px)"

Not sure if this will help a lot. Sometimes the colors for similar branch names, say version-1 and version-2, look almost identical, and sometimes they look completely different. I'm not sure if basing the color generation on date/time stamps will really produce more variability.

I think the color space is intentionally limited to restrict variability, probably based on feedback by color-blind users, as mentioned by Stephan.

BTW: For users concerned about readability:

Despite some recent enhancements for the default skin, most of the light-mode skins don't use black text color, and most of the dark-mode skins don't use white text color. Changing the skin to display text in black or white instead of grayish improves readability, especially for areas with another background color.

Thoughts:

I'm often "transplanting" (partial) branches across repositories, would they have different colors (even for the same branch name) on each repository if the commit time by the script is different?

What about reusing merged and closed branch names, would each reused branch section look different?

Yes/yes gets a -1/-1 vote from me, I think.

Hm, indeed looks like a -1/-1 from me.

I prefer "moved" and reopened branches to have the same colors.

What's the best behavior here? Current behavior? Old behavior? New behavior using timestamp? A combination?

FWIW, i like/prefer what you've done but...

Branch color behavior is such a subjective thing that it's going to be a challenge to reach consensus.

... also have no strong preference. It's one of those things which goes unnoticed until there's a color collision, then the collision eventually passes as branches come and go, so no real harm done.

Y'all work it out and i'll be happy with what i get :).

Consider a more long-running branch that was reused:

http://fossil.bradfords.org:8282/fossil/timeline?r=js-hamburger-menu

This is the definitive show-stopper for me, and I prefer to stick with the current behavior. And yes, I really want branches with the same name look the same across various repositories.

But note that I can easily patch this for my private version of Fossil if you need something fresh (and confusing) to look at! ;-)

I think the magic is in reasonable_bg_color(), which limits the available color space, maybe just for light/dark, maybe also for color blindness. No matter how "random" the input hash is.

Enabling raw-bgcolor may give more variation, but also less readabaility.

BTW: I think the Tcl/Tk folks use a lot of explicit colors for their branches.

And here.

What about using MD5 to generate the color hashes?

This would definitively help for the names like "something_v1" / "something_v2" generated branch color that are indistinguishable.

No, it wouldn't.

It's not a problem of "randomness", i.e. similar branch names can be assigned very similar or very different branch colors, see this example:

• https://fossil-scm.org/home/hash-color-test?b0=something_v0&b1=something_v1&b2=something_v2&b3=something_v3&b4=something_v4&b5=something_v5&b6=something_v6&b7=something_v7&b8=something_v8&b9=something_v9

It's a problem of the narrowed color space, due to background-foreground and probably color blindness requirements.

Ok, now I got it.

This one indeed seems to have more variation:

• http://fossil.bradfords.org:8484/fossil/hash-color-test?b0=something_v0&b1=something_v1&b2=something_v2&b3=something_v3&b4=something_v4&b5=something_v5&b6=something_v6&b7=something_v7&b8=something_v8&b9=something_v9

Andy, good job! Sorry it took me so long to grasp!

On the other hand ...

This one has also quite a few potential conflicts:

• http://fossil.bradfords.org:8484/fossil/hash-color-test?b0=another-thing-v0&b1=another-thing-v1&b2=another-thing-v2&b3=another-thing-v3&b4=another-thing-v4&b5=another-thing-v5&b6=another-thing-v6&b7=another-thing-v7&b8=another-thing-v8&b9=another-thing-v9

Maybe even more than with the current approach:

• https://fossil-scm.org/home/hash-color-test?b0=another-thing-v0&b1=another-thing-v1&b2=another-thing-v2&b3=another-thing-v3&b4=another-thing-v4&b5=another-thing-v5&b6=another-thing-v6&b7=another-thing-v7&b8=another-thing-v8&b9=another-thing-v9

My opinion tends to go back to Post 32.

Here's a visual map of the branch colors from five different versions of Fossil with five different methods to generate branch colors.

The first block is sorted by branch modification time and illustrates color collisions. The second block is sorted by color and illustrates color distribution.

So maybe randomization is not the problem, after all?

So maybe randomization is not the problem, after all ...

But the fact that there's effectively only about 8 distinct colors?

May be, but at the end it happens *v1 and *v2 always have this problem and having a way to override the color easily and at the same time having it to work with dark and light theme would be useful.

I don’t know what would be the best way to do that, but now the only way to override is to force a manual color which can become unusable on different theme.

Perhaps we could have the manually selected color to pass through this kind of process ?

See reply 33.

I think, what we need is just a way to override a color when needed (collision or just because one don't like the generated color).

Pehaps we could keep original behavior (based on the branch name), but we could have an option to override with an alternate input string just for the color generation.

• Were we edit the checkin, we have option to override the color like now, but it could be a button that generate a random string, the user could press this button until he is happy with the color.
  • So now the color we override can work with different theme.

I think this is very useful.. with timestamp, color collision can still happens we may still want to override the color.

We already have:

• fossil ci → --branchcolor
• fossil amend → --branchcolor
• /ci_edit → newclr

Putting a "random string" somewhere (where? would it sync? etc.) just for color generation seems whacky.

A minimally invasive solution might be that the /ci_edit web UI provides facilities to generate a random branch (or check-in, i.e. propagating or non-propagating) color that simply changes the bgcolor special tag, as it already does if a color is set manually. But this still feels like overengineering, if the user is already in the /ci_edit page, they can just pick any color they like, themselves.

BTW: A random color may work well due to recent changes by Richard to auto-adjust all colors to light or dark mode.

Putting a "random string" somewhere (where? would it sync? etc.) just for color generation seems whacky.

It is overengineering for sure, but using some tag as a addendum to branch name for color choosing will allow simple changing of conflicting colors for similarly named branches with one mouse click (if a button for setting it will be available somewhere).

Introducing a new special tag brings quite some overhead: it has to be explicitly ignored in many places so as not to show up as an ordinary tag, and many UI and CLI commands need new facilities to use or modify it.

Note that with the recent changes to background color handling linked in a previous post, you can do:

fossil amend start:"BRANCHNAME" --branchcolor="orange"

Fossil will now translate "orange" to a numeric form and auto-adjust it for light and dark themes.

Also see the Background Color Test page.

BTW: the /brlist?colors=on page provides a good overview of branch colors and readability (not yet updated in your examples).

Here are the changes I introduced in...

My eyes thank you!

The one(?) down-side is that we're using the timestamp of the most recent checkin, so each branch's colors may change at any moment. What if, instead, we use the timestamp of the start of the branch using the special name "start:branchname"?

:-?

Yes, I also prefer stable colors.

My ftime CLI script does "cyclic" color allocation, and I don't like it. I expect this to be even more irritating with web UI background colors.

My patched version of Fossil does "whitewashing" of colors (for light-mode skins). This looked great with the "old" algorithm pointed out by Andy and had more diverse colors than the "new" (current) one.

PS: The transparent SVG backgrounds to mix in white (or black, for dark-mode skins) correspond to alpha-blending and could also be calculated directly on the "old" algorithm instead of being applied through SVG backgrounds.

PPS: Overall, I think the branch coloring system is pretty decent with the latest recent changes from drh, and if branch color collision is a real problem, it's easy to assign a user-defined color to some long-running branch, for example.