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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).