git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>, git@vger.kernel.org
Subject: Re: [PATCH] Allow selection of different cleanup modes for commit messages
Date: Fri, 21 Dec 2007 23:59:34 -0800	[thread overview]
Message-ID: <7v3atv17o9.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20071221230851.GA3260@steel.home> (Alex Riesen's message of "Sat, 22 Dec 2007 00:08:51 +0100")

Alex Riesen <raa.lkml@gmail.com> writes:

> Junio C Hamano, Fri, Dec 21, 2007 22:43:49 +0100:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>> 
>> > The patch is on top of my previos patches. Junio, if you wish, I can
>> > squash and resend.
>> 
>> That would be a sane thing to do.
>
> Done

Thanks.  I am afraid I have to ask you to either refute my
misunderstanding or a second round.

> +--cleanup=<mode>::
> +	This option sets how the commit message is cleaned up.
> +	The  '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
> +	and 'default'. The 'default' mode will strip leading and
> +	trailing empty lines and #commentary from the commit message
> +	only if the message is to be edited. Otherwise only whitespace
> +	removed. The 'verbatim' mode wont change message at all,
> +	'whitespace' removes just leading/trailing whitespace lines
> +	and 'strip' removes both whitespace and commentary.

(minor) s/wont/does not/

> @@ -394,20 +410,24 @@ static int prepare_log_message(const char *index_file, const char *prefix)
>  		return !!DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES);
>  	}
>  
> +	if (!no_edit) {
> +		if (in_merge)
> +			fprintf(fp,
> +				"#\n"
> +				"# It looks like you may be committing a MERGE.\n"
> +				"# If this is not correct, please remove the file\n"
> +				"#	%s\n"
> +				"# and try again.\n"
> +				"#\n",
> +				git_path("MERGE_HEAD"));
> +		if (cleanup_mode != CLEANUP_NONE)
> +			fprintf(fp,
> +				"\n"
> +				"# Please enter the commit message for your changes.\n");
> +		if (cleanup_mode == CLEANUP_DEFAULT)
> +			fprintf(fp,
> +				"# (Comment lines starting with '#' will not be included)\n");

Can't cleanup_mode be CLEANUP_ALL at this point, and if so
shouldn't this insn be given as well?

In addition, if:

 - we are talking with editor, and
 - the mode is verbatim, and
 - we added any "#" line ourselves (e.g. in_merge adds the insn
   shown above, or perhaps we added "git status" output),

then perhaps we would want to say that "#" lines need to be
stripped by the user; otherwise it will be left in the commit.

> @@ -431,10 +451,13 @@ static int message_is_empty(struct strbuf *sb, int start)
>  	const char *nl;
>  	int eol, i;
>  
> +	if (cleanup_mode == CLEANUP_NONE && sb->len)
> +		return 0;
> +
>  	/* See if the template is just a prefix of the message. */
>  	strbuf_init(&tmpl, 0);
>  	if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
> -		stripspace(&tmpl, 1);
> +		stripspace(&tmpl, !no_edit);

We at this point know that some stripping would happen.  The
template needs to be cleaned the same way as the commit message
was stripped.  Is checking no_edit the right thing to do?  What
if cleanup_mode was CLEANUP_ALL and there is no editing going
on?

> @@ -813,7 +846,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>  	if (p != NULL)
>  		strbuf_setlen(&sb, p - sb.buf + 1);
>  
> -	stripspace(&sb, 1);
> +	if (cleanup_mode != CLEANUP_NONE)
> +		stripspace(&sb, cleanup_mode == CLEANUP_DEFAULT ?
> +			   !no_edit: cleanup_mode == CLEANUP_ALL);

When writing such a long ? : expression, laying it out like:

	condition
        ? if-true
        : if-false

would be easier to read.  You tilt your head sideways 90
degrees, just like you read a smiley ;-), and you will see the
parse tree.

But I suspect, assuming that the two issues around CLEANUP_DEFAULT vs
CLEANUP_ALL I mentioned above are indeed bugs, it may be cleaner
to:

  - parse the options; you get one of NONE/DEFAULT/SPACE/ALL

  - convert DEFAULT to SPACE or ALL if editor is in effect.

  - do not worry about no_editor or DEFAULT in the rest of the
    code when calling stripspace().  The only values you will
    see are NONE, SPACE or ALL.

> diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
> index 21ac785..6219378 100755
> --- a/t/t7502-commit.sh
> +++ b/t/t7502-commit.sh
> @@ -89,4 +89,44 @@ test_expect_success 'verbose' '
>  
>  '
>  
> +test_expect_success 'verbatim commit messages' '
> +

These tests check too many things at once, and it would be very
hard to diagnose when breakage does happen.  Please split them
perhaps into three separate tests like this:

> +	echo >>negative &&
> +	{ echo;echo "# text";echo; } >expect &&
> +	git commit --cleanup=verbatim -t expect -a &&
> +	git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
> +	diff -u expect actual &&

This is one test --- making sure the commit body match the
unedited template verbatim, except the status part to be shown
in the editor.  But we are not using editor in this test and I
thought the point of this --cleanup=verbatim exercise was that
the "status" part is not even have to be added to the commit log
message when editor is not in effect...  Isn't the "head -n 3"
just sweeping a bug under the rug?

> +	echo >>negative &&
> +	git commit --cleanup=verbatim -F expect -a &&
> +	git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
> +	diff -u expect actual &&

And this is another test.

> +	echo >>negative &&
> +	git commit --cleanup=verbatim -m "$(cat expect)" -a &&
> +	git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
> +	diff -u expect actual

And this is yet another.

> +'

Also, the tests do not check "-F file -e", "-m msg -e" etc.  We
would want to make sure the right insn are shown to the user in
the editor, wouldn't we?

  reply	other threads:[~2007-12-22  8:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-20 21:18 [PATCH] git-commit: add --verbatim to allow unstripped commit messages Alex Riesen
2007-12-20 21:40 ` Linus Torvalds
2007-12-20 23:33   ` Alex Riesen
2007-12-20 23:35     ` Alex Riesen
2007-12-20 23:37       ` [PATCH] Only filter "#" comments from commits if the editor is used Alex Riesen
2007-12-20 23:39         ` Junio C Hamano
2007-12-20 23:43           ` Alex Riesen
2007-12-20 23:43         ` Junio C Hamano
2007-12-20 23:48       ` [PATCH] Fix thinko in checking for commit message emptiness Alex Riesen
2007-12-20 23:55     ` [PATCH] git-commit: add --verbatim to allow unstripped commit messages Linus Torvalds
2007-12-21  0:14       ` Björn Steinbrink
2007-12-21  0:49         ` Linus Torvalds
2007-12-20 23:50   ` Junio C Hamano
2007-12-21  0:03     ` Linus Torvalds
2007-12-21 17:35       ` [PATCH] Allow selection of different cleanup modes for " Alex Riesen
2007-12-21 21:43         ` Junio C Hamano
2007-12-21 23:08           ` Alex Riesen
2007-12-22  7:59             ` Junio C Hamano [this message]
2007-12-22 18:46               ` Alex Riesen
2007-12-22 19:18                 ` Linus Torvalds
2007-12-22 19:41                   ` Junio C Hamano
2007-12-23  3:01                   ` Junio C Hamano
2007-12-23  3:46                     ` 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=7v3atv17o9.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=raa.lkml@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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).