From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Jeff King <peff@peff.net>, Nanako Shiraishi <nanako3@lavabit.com>
Subject: Re: [PATCH] graph API: Added logic for colored edges
Date: Wed, 08 Apr 2009 00:59:10 -0700 [thread overview]
Message-ID: <7vd4bnpodt.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20090407185724.GA9996@linux.vnet> (Allan Caffee's message of "Tue, 7 Apr 2009 14:57:24 -0400")
Allan Caffee <allan.caffee@gmail.com> writes:
> @@ -72,11 +69,21 @@ 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.
> */
> + const char *color;
You already use short for git_graph.default_column_color and I suspect in
the longer term you want to make this one an index into column_colors[]
array the same way. We may someday decide to support non-ANSI color
scheme using ncurses or something, and at that point the "hardware color"
constants like GIT_COLOR_RED and friends may change from strings to small
integers we use to call our (yet to be written) curses interface layer
with.
> @@ -312,6 +343,33 @@ static struct commit_list *first_interesting_parent(struct git_graph *graph)
> return next_interesting_parent(graph, parents);
> }
>
> +static const char* graph_get_current_column_color(const struct git_graph* graph)
Style. Asterisk comes next to identifiers, not types (the parameter to
graph_increment_column_color has the same issue).
static const char *graph_...color(const struct git_graph *graph)
> @@ -596,7 +661,7 @@ static void graph_output_padding_line(struct git_graph *graph,
> * Output a padding row, that leaves all branch lines unchanged
> */
> for (i = 0; i < graph->num_new_columns; i++) {
> - strbuf_addstr(sb, "| ");
> + strbuf_write_column(sb, &graph->new_columns[i], "| ");
Hmmm, this forbids us to use reverse color in the color palette because
that would highlight the trailing whitespace. Is that something we care
about, or a reversed "|", "/" and "\" are already too ugly that we won't
want to support them?
> @@ -648,8 +713,11 @@ static void graph_output_pre_commit_line(struct git_graph *graph,
> for (i = 0; i < graph->num_columns; i++) {
> struct column *col = &graph->columns[i];
> if (col->commit == graph->commit) {
> + struct strbuf tmp = STRBUF_INIT;
> seen_this = 1;
> - strbuf_addf(sb, "| %*s", graph->expansion_row, "");
> + strbuf_addf(&tmp, "| %*s", graph->expansion_row, "");
> + strbuf_write_column(sb, col, tmp.buf);
> + strbuf_release(&tmp);
Same here.
> @@ -662,13 +730,13 @@ static void graph_output_pre_commit_line(struct git_graph *graph,
> */
> if (graph->prev_state == GRAPH_POST_MERGE &&
> graph->prev_commit_index < i)
> - strbuf_addstr(sb, "\\ ");
> + strbuf_write_column(sb, col, "\\ ");
> else
> - strbuf_addstr(sb, "| ");
> + strbuf_write_column(sb, col, "| ");
> } else if (seen_this && (graph->expansion_row > 0)) {
> - strbuf_addstr(sb, "\\ ");
> + strbuf_write_column(sb, col, "\\ ");
> } else {
> - strbuf_addstr(sb, "| ");
> + strbuf_write_column(sb, col, "| ");
> }
> }
Likewise.
> @@ -744,14 +813,25 @@ static void graph_output_commit_line(struct git_graph *graph, struct strbuf *sb)
> if (graph->num_parents < 3)
> strbuf_addch(sb, ' ');
> else {
> + /*
> + * Here dashless_commits represents the
> + * number of parents which don't need
> + * to have dashes (because their edges
> + * fit neatly under the commit).
> + */
> + const int dashless_commits = 2;
> int num_dashes =
> - ((graph->num_parents - 2) * 2) - 1;
> + ((graph->num_parents - dashless_commits) * 2) - 1;
> for (j = 0; j < num_dashes; j++)
> - strbuf_addch(sb, '-');
> - strbuf_addstr(sb, ". ");
> + strbuf_write_column(sb,
> + &graph->new_columns[(j / 2) + dashless_commits],
> + "-");
> + strbuf_write_column(sb,
> + &graph->new_columns[(j / 2) + dashless_commits],
> + ". ");
The nesting seems to be becoming too deep and the body of the for loop is
getting too long. Time to make it a helper function that handles only one
column, perhaps?
next prev parent reply other threads:[~2009-04-08 8:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090331235922.GA7411@linux.vnet>
2009-04-07 18:57 ` [PATCH] graph API: Added logic for colored edges Allan Caffee
2009-04-08 7:59 ` Junio C Hamano [this message]
2009-04-08 21:41 ` Allan Caffee
2009-04-09 0:29 ` Junio C Hamano
2009-04-09 22:22 ` [PATCH v3] " Allan Caffee
2009-04-12 8:44 ` Junio C Hamano
2009-04-12 17:43 ` Allan Caffee
2009-04-12 18:45 ` Junio C Hamano
2009-04-12 20:27 ` [PATCH v4] " Allan Caffee
2009-04-12 21:59 ` Junio C Hamano
2009-04-13 19:53 ` [PATCH v5] " Allan Caffee
2009-04-09 17:58 ` [PATCH] " Teemu Likonen
2009-04-09 22:08 ` Allan Caffee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vd4bnpodt.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=nanako3@lavabit.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.