From: Jens Lehmann <Jens.Lehmann@web•de>
To: Junio C Hamano <gitster@pobox•com>
Cc: Git Mailing List <git@vger•kernel.org>, Jeff King <peff@peff•net>,
Johannes Sixt <j6t@kdbg•org>, Ari Pollak <ari@debian•org>,
Ramsay Jones <ramsay@ramsay1•demon.co.uk>
Subject: Re: [PATCH v3] commit -v: strip diffs and submodule shortlogs from the commit message
Date: Thu, 21 Nov 2013 22:26:06 +0100 [thread overview]
Message-ID: <528E7A6E.8080603@web.de> (raw)
In-Reply-To: <xmqqpppu65fs.fsf@gitster.dls.corp.google.com>
Am 21.11.2013 00:04, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web•de> writes:
>> diff --git a/wt-status.c b/wt-status.c
>> index b4e44ba..734f94b 100644
>> --- a/wt-status.c
>> +++ b/wt-status.c
>> @@ -16,6 +16,9 @@
>> #include "column.h"
>> #include "strbuf.h"
>>
>> +static char wt_status_cut_line[] = /* 'X' is replaced with comment_line_char */
>> +"X ------------------------ >8 ------------------------\n";
>> +
>> static char default_wt_status_colors[][COLOR_MAXLEN] = {
>> GIT_COLOR_NORMAL, /* WT_STATUS_HEADER */
>> GIT_COLOR_GREEN, /* WT_STATUS_UPDATED */
>> @@ -767,6 +770,15 @@ conclude:
>> status_printf_ln(s, GIT_COLOR_NORMAL, "");
>> }
>>
>> +void wt_status_truncate_message_at_cut_line(struct strbuf *buf)
>> +{
>> + const char *p;
>> +
>> + p = strstr(buf->buf, wt_status_cut_line);
>> + if (p && (p == buf->buf || p[-1] == '\n'))
>> + strbuf_setlen(buf, p - buf->buf);
>> +}
>
> Perhaps it may happen that all the current callers have called
> wt_status_print_verbose() to cause wt_status_cut_line[0] to hold
> comment_line_char, but relying on that calling sequence somehow
> makes me feel uneasy.
I initialized the place to be occupied by the comment_line_char
in wt_status_cut_line with 'X' on purpose to notice such a
problem. But I'd be also fine with setting wt_status_cut_line[0]
again here just to be sure. But please also see below ...
> Perhaps cut_line[] should only have "--- >8 ---" part and both
> printing side (below) and finding side (this one) should check these
> separately?
... ok ...
> That is:
>
> p = buf->buf;
> while (p && *p) {
> p = strchr(p, comment_line_char);
> if (!p)
> break;
> if (strstr(p + 1, cut_line) == p + 1)
> break;
> p++;
> continue;
> }
> if (p && *p && (p == buf->buf || p[-1] == '\n'))
> strbuf_setlen(buf, p - buf->buf);
>
> or something (the above is deliberately less-efficient-than-ideal,
> because I want to keep the code structure in such a way that we can
> later turn comment_line_char to a string[] that can hold "//" to
> allow a multi-char comment introducer more easily)?
Hmm, I'm a bit reluctant to go that far to optimize this patch for
another one that might materialize later. But what about this:
struct strbuf cut_line = STRBUF_INIT;
strbuf_addf(&cut_line, "%c %s", comment_line_char, wt_status_cut_line);
p = strstr(buf->buf, cut_line.buf);
if (p && (p == buf->buf || p[-1] == '\n'))
strbuf_setlen(buf, p - buf->buf);
strbuf_release(&cut_line);
That is shorter can easily be adapted to a comment line string later.
And even though it's slightly less performant should not be a problem
here as this happens only once after invoking an editor for user input.
>> static void wt_status_print_verbose(struct wt_status *s)
>> {
>> struct rev_info rev;
>> @@ -787,10 +799,17 @@ static void wt_status_print_verbose(struct wt_status *s)
>> * If we're not going to stdout, then we definitely don't
>> * want color, since we are going to the commit message
>> * file (and even the "auto" setting won't work, since it
>> - * will have checked isatty on stdout).
>> + * will have checked isatty on stdout). But we then do want
>> + * to insert the scissor line here to reliably remove the
>> + * diff before committing.
>> */
>> - if (s->fp != stdout)
>> + if (s->fp != stdout) {
>> rev.diffopt.use_color = 0;
>> + wt_status_cut_line[0] = comment_line_char;
>> + fprintf(s->fp, wt_status_cut_line);
>> + fprintf(s->fp, _("%c Do not touch the line above.\n"), comment_line_char);
>> + fprintf(s->fp, _("%c Everything below will be removed.\n"), comment_line_char);
>> + }
>
> I didn't bother with my "how about this" version, but we may want to
> use strbuf_add_commented_lines() to help i18n/l10n folks. Depending
> on the l10n, this message may want to become more or less than 2
> lines.
Makes sense, will change that (maybe using strbuf_commented_addf()
instead) for v4.
next prev parent reply other threads:[~2013-11-21 21:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-20 22:31 [PATCH v3] commit -v: strip diffs and submodule shortlogs from the commit message Jens Lehmann
2013-11-20 23:04 ` Junio C Hamano
2013-11-21 21:26 ` Jens Lehmann [this message]
2013-11-21 22:23 ` Junio C Hamano
2013-12-05 19:44 ` [PATCH v4] " Jens Lehmann
2013-12-05 20:05 ` Junio C Hamano
2013-12-05 23:10 ` Junio C Hamano
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=528E7A6E.8080603@web.de \
--to=jens.lehmann@web$(echo .)de \
--cc=ari@debian$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=j6t@kdbg$(echo .)org \
--cc=peff@peff$(echo .)net \
--cc=ramsay@ramsay1$(echo .)demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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