Colors in a three way merge

[Michael Bulgrien]

I would like to ressurrect a discussion on color since there are more in the beta now:

February 21st, 2007 at 3:21 pm
Ever since I joined the beta, I’ve always thought purple and blue were too close to each other which makes it difficult for me to remember which color is which. Purple, being a combination of both Red and Blue, adds to the confusion. My subconscious processes the association even though there is no corresponding functional association. I’ve always thought that Blue and Green would have been better choices for the LHS and RHS panes as they are more distinct and neither color contains Red. Those that use memory helps like I do would find the association easier to remember since the second letter of each color would then reflect the side that it represents: bLue for Left & gReen for Right.

February 21st, 2007 at 6:21 pm
Magenta/Purple would do better in the middle pane. The basic psychology of color and how it affects the human psyche comes into play, here.

Blue and Green are cool (relaxful) colors. Magenta and Pink are warmer (less relaxful) colors. Operating systems often default the desktop to shades of blue or green to keep users relaxed instead of keyed up and irritated. Studies show that red-based colors cause increased stress in most people.

In a 3-way merge effort, one usually expects differences to resolve to the LHS, the RHS, or a combination of the two. It is not often that differences will resolve to the common ancestor (middle pane). If the LHS and RHS were blue and green, then the output pane would become calmer and more peaceful as conflicts were resolved. In other words, the colors would emphasize that things are okay.

When there are outstanding conflicts and situations in which the center section was taken in place of conflicting differences in the LHS and RHS, then the output pane would contain the warmer red and purple colors appropriately “warning” the user that things might not be okay. This way, the colors serve a secondary purpose (appropriately relaxing or stimulating the user based on the actual merge effort) rather than simply differentiating between Left, Right and Middle.

And finally, rather than using purple at all, why not use a distinctly different color for the common ancestor (Think Perforce/Gold)

February 21st, 2007 at 4:01 pm
Michael B:

Interesting ideas about color. As you can imagine, it’s something we’ve been struggling with. Subtle differences in color can look great on one monitor and be lost on another. I had written up a Color Concepts topic early on, but it was obsolete before I had a chance to post it. I’ll try to get it updated and posted to continue the discussion.

Tim

Colors haven't changed since I initiated this discussion a year ago.
I'm curious as to what your thoughts about it are now, Tim.

[Michael Bulgrien]

By the way, I've never used Perforce...and I was not aware that perforce had the same Left/Right color order that I was recommending when I first suggested it. I wonder what their rationale was?

[Tim]

I'm currently working on an easier method for setting colors. I have no problem with our teal and purple defaults, but it should be easy to change them or tweak them for your monitor (and it's not now).

Perforce has only three colors to worry about. Cirrus also has important vs. unimportant, foreground coloring for specific differences, and syntax highlighting. We use yellow for "edited".

Once we improve color editing, I'll invite users to submit their favorite settings. We may have a selection of preset schemes built in to BC3.

[Tim]

Michael, try setting your merge colors to green and blue (with the new Compare Colors mechanism) and let me know how it goes. Craig has done so here and it looks pretty good.

[Michael Bulgrien]

Thanks, Tim. I've played with the colors quite a bit... I do like the new defaults better than the old, so I may leave the defaults in place for a while. You mentioned the possibility of providing a way for users to choose between several color "themes". I'll submit something it that ever gets implemented.

[Roman Starkov]

I've always been confused by the fact that "same change" is highlighted as "left change" in merge. This makes no sense to me - same change requires completely different consideration than left-only change. Could this have simply been overlooked or is this the way it's meant to be? (or am I missing something altogether? )