Colorization of log --graph

I know that _some_ people arn't particularly fond of colors, but I was wondering how difficult it would be to colorize the edges on the --graph drawn by the log command? It can be a little tricky trying to follow them with a relatively complex history. I was thinking something like gitk already does.

Is anybody else interested in seeing this?

Hi,

Quoted 5 lines · Allan Caffee

I know that _some_ people arn't particularly fond of colors, but I was wondering how difficult it would be to colorize the edges on the --graph drawn by the log command? It can be a little tricky trying to follow them with a relatively complex history. I was thinking something like gitk already does.

That's a good idea! (And it is mentioned as a TODO in graph.c...)

Quoted 1 line

Is anybody else interested in seeing this?

Count me in. Are you interested in implementing this?

If so:

- you need to #include "color.h" in graph.c

- you need to insert a color identifier into struct column (there is an XXX comment at the correct location)

- you need to find a way to determine colors for the branches

- you need to put the handling into the function graph_output_pre_commit_line() in graph.c (and probably graph_output_commit_char(), graph_output_post_merge_line(), graph_output_collapsing_line(), graph_padding_line(), and graph_output_padding_line(), too)

- it would make sense IMHO to introduce a new function that takes a pointer to an strbuf, a pointer to a struct column and a char (or maybe a string) that adds the appropriately colorized char (or string) to the strbuf

- use the global variable diff_use_color to determine if the output should be colorized at all

- probably you need to make an array of available colors or some such (which might be good to put into color.[ch])

Hello and thanks for the speedy reply!

Quoted 5 lines · Johannes Schindelin

Quoted 1 line · Allan Caffee

Is anybody else interested in seeing this?

Count me in. Are you interested in implementing this?

I'll give it a go. Been a while since I've done anything of substance in pure C so it should be a nice refresher. :)

Quoted 6 lines

If so:

- you need to #include "color.h" in graph.c

- you need to insert a color identifier into struct column (there is an XXX comment at the correct location)

By color identifier I assume you mean the ANSI escape sequence, right? I didn't see a type for representing colors in color.{c,h} other than the int it seems to use internally.

Quoted 1 line

- you need to find a way to determine colors for the branches

Okay, so if we were to make this similiar to how gitk works it would
involve: If the previous commit was a merge:

	for (i = 0; i < graph->num_columns; i++)
		graph->columns[i]->color = get_next_column_color();
else
	get_current_column_color();

I was thinking of storing the current color by adding a default_column_color attribute to git_graph that serves as an index into column_colors. column_colors being the array of available colors.

Quoted 6 lines

- you need to put the handling into the function graph_output_pre_commit_line() in graph.c (and probably graph_output_commit_char(), graph_output_post_merge_line(), graph_output_collapsing_line(), graph_padding_line(), and graph_output_padding_line(), too)

Quoted 4 lines

- it would make sense IMHO to introduce a new function that takes a pointer to an strbuf, a pointer to a struct column and a char (or maybe a string) that adds the appropriately colorized char (or string) to the strbuf

That makes sense. Then we can just update the functions you mentioned above to use this.

Quoted 2 lines

- use the global variable diff_use_color to determine if the output should be colorized at all

The function for adding a column to an strbuf would offer a convenient place to put the condition.

Quoted 2 lines

- probably you need to make an array of available colors or some such (which might be good to put into color.[ch])

This would be the color_codes array I mentioned but it seems like it might belong in graph.c. There's something similiar in diff.c and it seems like this is more related to graphing then to colors in general. Although I do think it makes sense to #define some of the more common ANSI codes there so that they don't have to be duplicated. grep shows 6 occurrences of '\033[31m', the code for red foreground.

I'd start like this:

	enum color_name {
		COLOR_RESET,
		COLOR_RED,
		COLOR_GREEN,
		COLOR_YELLOW,
		COLOR_BLUE,
		COLOR_MAGENTA,
		COLOR_CYAN,
		COLOR_WHITE
	};

Quoting Johannes Schindelin <[email protected]>:

Quoted 12 lines

I'd start like this:

      enum color_name {
              COLOR_RESET,
              COLOR_RED,
              COLOR_GREEN,
              COLOR_YELLOW,
              COLOR_BLUE,
              COLOR_MAGENTA,
              COLOR_CYAN,
              COLOR_WHITE
      };

Looking for "COLOR_RED" in the archive gives:

 http://article.gmane.org/gmane.comp.version-control.git/109676

/*
* Map names to ANSI escape sequences. Consider putting this in color.c
* and providing color_name_get_ansi_code(enum color_name). */
const char* git_color_codes[] {
GIT_COLOR_RESET,
GIT_COLOR_BOLD,
GIT_COLOR_RED,
GIT_COLOR_GREEN,
GIT_COLOR_YELLOW,
GIT_COLOR_BLUE,
GIT_COLOR_CYAN,
GIT_COLOR_BG_RED,
};

That conveniently offers clients access to both the raw escape codes and a clear type for storing/handling colors.

Modified the graph drawing logic to colorize edges based on parent-child relationships similiarly to gitk.

Signed-off-by Allan Caffee <[email protected]>

I havn't gotten the chance to do any of the color clean up that's been discussed on this thread. I'll try to throw something together in a seperate patch series.

Also this patch isn't respecting the --no-color option which I imagine means that diff_use_color_default isn't the right variable to be checking. Johannes mentioned using diff_use_color but the only instance I see is a parameter to diff_get_color. What am I missing?

graph.c +3 -2

index 162a516..2929c8b 100644
@@ -72,11 +74,22 @@ struct column {
 	 */
 	struct commit *commit;
 	/*
-	 * XXX: Once we add support for colors, struct column could also
-	 * contain the color of its branch line.
+	 * The color to (optionally) print this column in.
 	 */
+	char *color;
 };
 
+static void strbuf_write_column(struct strbuf *sb, const struct column *c,

graph.c +11 -0

@@ -86,6 +99,24 @@ enum graph_state {
 	GRAPH_COLLAPSING
 };
 
+/*
+ * The list of available column colors.
+ */
+static char column_colors[][COLOR_MAXLEN] = {
+	GIT_COLOR_RED,
+	GIT_COLOR_GREEN,
+	GIT_COLOR_YELLOW,
+	GIT_COLOR_BLUE,
+	GIT_COLOR_MAGENTA,
+	GIT_COLOR_CYAN,
+	GIT_COLOR_BOLD GIT_COLOR_RED,

How about this function instead?

static void strbuf_add_column(struct strbuf *sb,
const struct column *column, const char *fmt, ...)

{
        va_list ap;

        va_start(ap, fmt);
	if (column->color)
		strbuf_addstr(sb, column->color);
        strbuf_vaddf(sb, fmt, ap);
	if (column->color)
		strbuf_addstr(sb, GIT_COLOR_RESET);
        va_end(ap);
}

Hmm?

Quoted 16 lines · Johannes Schindelin

How about this function instead?

static void strbuf_add_column(struct strbuf *sb,
const struct column *column, const char *fmt, ...)

{
        va_list ap;

        va_start(ap, fmt);
	if (column->color)
		strbuf_addstr(sb, column->color);
        strbuf_vaddf(sb, fmt, ap);
	if (column->color)
		strbuf_addstr(sb, GIT_COLOR_RESET);
        va_end(ap);
}

Quoted 1 line

Hmm?

Except the strbuf_vaddf() is only in your private repository ;)

Signed-off-by Johannes Schindelin <[email protected]>

---

I'd actually like to see this and the next patch squashed in.

 graph.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

graph.c +0 -0

index 2929c8b..5e2f224 100644

graph.c +0 -2

 			strbuf_addf(&tmp, "| %*s", graph->expansion_row, "");
 			strbuf_write_column(sb, col, tmp.buf);
 			strbuf_release(&tmp);

@@ -921,8 +921,6 @@ static void graph_output_collapsing_line(struct git_graph *graph, struct strbuf
 {
 	int i;
 	int *tmp_mapping;
-	static int collapsing_columns[255];
-	int collapsing_seen_so_far = 0;
 
 	/*
 	 * Clear out the new_mapping array

Signature · 1 line

1.6.2.1.493.g67cf3

Quoted 5 lines

graph.c +0 -0

index 2929c8b..5e2f224 100644
@@ -701,8 +701,8 @@ static void graph_output_pre_commit_line(struct git_graph *graph,

graph.c static void graph_output_pre_commit_line(struct git_graph *graph, · line 705

Quoted 6 lines

graph.c +1 -1

 	for (i = 0; i < graph->num_columns; i++) {
 		struct column *col = &graph->columns[i];
 		if (col->commit == graph->commit) {
-			seen_this = 1;
 			struct strbuf tmp = STRBUF_INIT;
+			seen_this = 1;

Which codebase are you working on top of?

Quoted 15 lines · Nanako Shiraishi

Quoting Johannes Schindelin <[email protected]>:

Quoted 12 lines

I'd start like this:

      enum color_name {
              COLOR_RESET,
              COLOR_RED,
              COLOR_GREEN,
              COLOR_YELLOW,
              COLOR_BLUE,
              COLOR_MAGENTA,
              COLOR_CYAN,
              COLOR_WHITE
      };

Quoted 4 lines

Looking for "COLOR_RED" in the archive gives:

 http://article.gmane.org/gmane.comp.version-control.git/109676

Duly noted. Perhaps those #defines should be relocated to color.h?

If we still wanted to provide a color_name type we could use GIT_COLOR_NAME_RESET et al. That would give us something like:

#define GIT_COLOR_NORMAL ""
#define GIT_COLOR_RESET "\033[m"
#define GIT_COLOR_BOLD "\033[1m"
#define GIT_COLOR_RED "\033[31m"
#define GIT_COLOR_GREEN "\033[32m"
#define GIT_COLOR_YELLOW "\033[33m"
#define GIT_COLOR_BLUE "\033[34m"
#define GIT_COLOR_CYAN "\033[36m"
#define GIT_COLOR_BG_RED "\033[41m"

enum color_name {
GIT_COLOR_NAME_NORMAL
GIT_COLOR_NAME_RESET,
GIT_COLOR_NAME_RED,
GIT_COLOR_NAME_GREEN,
GIT_COLOR_NAME_YELLOW,
GIT_COLOR_NAME_BLUE,
GIT_COLOR_NAME_MAGENTA,
GIT_COLOR_NAME_CYAN,
GIT_COLOR_NAME_WHITE
GIT_COLOR_NAME_BG_RED
};

/*
* Map names to ANSI escape sequences. Consider putting this in color.c
* and providing color_name_get_ansi_code(enum color_name). */
const char* git_color_codes[] {
GIT_COLOR_RESET,
GIT_COLOR_BOLD,
GIT_COLOR_RED,
GIT_COLOR_GREEN,
GIT_COLOR_YELLOW,
GIT_COLOR_BLUE,
GIT_COLOR_CYAN,
GIT_COLOR_BG_RED,
};

That conveniently offers clients access to both the raw escape codes and a clear type for storing/handling colors.

I know that _some_ people arn't particularly fond of colors, but I was wondering how difficult it would be to colorize the edges on the --graph drawn by the log command? It can be a little tricky trying to follow them with a relatively complex history. I was thinking something like gitk already does. Is anybody else interested in seeing this?

~Allan

This may be clueless (I suspect that it is) but I have never understood the meaning of the different line colors in gitk. They seems arbitrary to me.

I get that the current HEAD is represented as a yellow dot, but that's it. (As an aside, it might be nice if merges had a different color dot than normal commits).

Can anyone clue me in?

Gitk paints lines of development (lineal history without merges nor forks) with the same color.

HTH,
Santi

Quoted 5 lines

Gitk paints lines of development (lineal history without merges nor forks) with the same color.

HTH,
Santi

Thanks for the quick reply. I suppose I realized that but it just doesn't seem that profound.
Don't get me wrong - I like gitk and still prefer it to any of the alternatives. But its of color seems more flashy than useful to me.

If scrolling through a history with many branches (so many parallel lines) like git.git, colors help you to follow a particular line.

I don't find it easy to follow a line in a PCB, where you normally don't have colors :)

Markus

2009/3/19 Markus Heidelberg <[email protected]>:

Quoted 4 lines

If scrolling through a history with many branches (so many parallel lines) like git.git, colors help you to follow a particular line.

Quoted 4 lines

I don't find it easy to follow a line in a PCB, where you normally don't have colors :)

Markus

I find it easier to simply click on the line and then click the parent in the lower window. Which I'm only mentioning b.c. others might not realize that it's possible.