threads / discuss / 28963

Uniform branch coloring

Subject: Uniform branch coloring

## tl;dr

2 messages between Nov 17, 2011 and Nov 30, 2011.

replies: 1people: 2as markdown or json

Nicolas Dudebout· Nov 17, 2011, 19:08 UTC · lore
Hi,

I was looking at the coloring of git branches in the output of different commands and had an idea. It seems to me that the color coding for branches should be uniform throughout.

It would for example be nice to be able to set current branch to be yellow and have it be yellow in: a) git branch -a b) git log --decorate c) git status d) git status --short --branch e) git checkout (this list is most likely not exhaustive)

As of now, you need to set the color of the current branch for each individual command. Here are the options you need to set: a) color.branch.current b) color.decorate.branch c) color.status.branch d) It is impossible to change the color (hard coded to green) e) It is not colored

I think the problems posed by this approach are clear:
- inconsistent coloring for the same object in different commands: a),
b), c), d), e)
- inconsistent coloring for the same object in the same command with
different options: c), d)
- inconsistent naming for the same object in different commands:
current in a), branch in b)
- impossibility to color some objects: d), e)
I have identified ways to address some of these problems:

[1] git status As the examples c) and d) show there is an inconsistency between the short and the default version of the command. There are two colors defined for the same element, namely WT_STATUS_LOCAL_BRANCH for the short version and WT_STATUS_ONBRANCH for the default version. One version should be picked and used in both instances. As this is done, it would be good to also give the opportunity to chose the color of the remote branch. <<This problem [1] is what I was trying to solve when I submitted a patch last night: http://article.gmane.org/gmane.comp.version-control.git/185563>>

[2] format_tracking_info(branch, &sb) The function format_tracking_info defined in remote.c is used in only two other files wt-status.c and builtin/checkout.c. It does not color the remote branches, the ahead or behind number (git status -sb to does the full coloring). It would be nice to have these colored.

[3] color naming
It would be nice to unify the naming of the colors meaning the same
thing. I could see using:
- current: for the current checked-out branch
- local: for other local branches
- remote: for remote branches

[4] single option for a type of branch It would be really useful to create a unique option config.color.branches.<slot> with <slot> in {current, local, remote}. This option could also be overwritten by specific command options such as color.status.current.

[1] can easily be done, once a color name has been decided [2] could be a little trickier since it is shared code between status and checkout (might need to solve [4] first) [3] should be easy but would create some compatibility issues [4] I do not know how easy it would be to implement. If git is structured the way it is right now, there is probably a good reason for it.

What are your thoughts on that?
Nicolas
Jeff King· Nov 30, 2011, 06:55 UTC · re: Nicolas Dudebout · lore

Re: Uniform branch coloring

On Thu, Nov 17, 2011 at 02:08:38PM -0500, Nicolas Dudebout wrote:
> I was looking at the coloring of git branches in the output of
> different commands and had an idea.
> It seems to me that the color coding for branches should be uniform throughout.

That sounds like a reasonable goal. At the very least all of the spots should be configurable, so you can make it uniform if you want to.

And then having unset config fallback to a "master" switch (e.g., if color.branch.current is unset, use color.default.branch or whatever). Which I think is close to what you write below.

> I have identified ways to address some of these problems:
> [...]

These all looked like reasonable goals to me. You will have to do a little refactoring, I'm sure.

> What are your thoughts on that?

Go for it. Your ideas sound sane. You might hit some ugly complexities in the implementation, but you won't know until you dig in and try. And patches are much easier to review (and apply!) than ideas. :)

-Peff

← back to recent threads