git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] revert: optionally refer to commit in the "reference" format
Date: Mon, 23 May 2022 15:25:18 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2205231507350.352@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqqsfp2b30k.fsf@gitster.g>

Hi Junio,

On Sat, 21 May 2022, Junio C Hamano wrote:

> A typical "git revert" commit uses the full title of the original
> commit in its title, and starts its body of the message with:
>
>     This reverts commit 8fa7f667cf61386257c00d6e954855cc3215ae91.
>
> This does not encourage the best practice of describing not just
> "what" (i.e. "Revert X" on the title says what we did) but "why"
> (i.e. and it does not say why X was undesirable).
>
> We can instead phrase this first line of the body to be more like
>
>     This reverts commit 8fa7f667 (do this and that, 2022-04-25)
>
> so that the title does not have to be
>
>     Revert "do this and that"
>
> We can instead use the title to describe "why" we are reverting the
> original commit.

Good idea, the `reference` text is so much more pleasant to read (and it
also makes things somewhat proof against rebasing and transitioning to
SHA-256).

> Introduce the "--reference" option to "git revert", and also the
> revert.reference configuration variable, which defaults to false, to
> tweak the title and the first line of the draft commit message for
> when creating a "revert" commit.

At some stage, we may even default to `revert.reference=true`?

> diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
> index bb92a4a451..8463fe9cf7 100644
> --- a/Documentation/git-revert.txt
> +++ b/Documentation/git-revert.txt
> @@ -117,6 +117,15 @@ effect to your index in a row.
>  	Allow the rerere mechanism to update the index with the
>  	result of auto-conflict resolution if possible.
>
> +--reference::
> +	Instead of starting the body of the log message with "This
> +	reverts <full object name of the commit being reverted>.",
> +	refer to the commit using "--pretty=reference" format
> +	(cf. linkgit:git-log[1]).  The `revert.reference`
> +	configuration variable can be used to enable this option by
> +	default.
> +
> +

Is that extra empty line intentional?

>  SEQUENCER SUBCOMMANDS
>  ---------------------
>  include::sequencer.txt[]
> diff --git a/builtin/revert.c b/builtin/revert.c
> index 51776abea6..ada51e46b9 100644
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -116,6 +116,8 @@ static int run_sequencer(int argc, const char **argv, struct replay_opts *opts)
>  			N_("option for merge strategy"), option_parse_x),
>  		{ OPTION_STRING, 'S', "gpg-sign", &opts->gpg_sign, N_("key-id"),
>  		  N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
> +		OPT_BOOL(0, "reference", &opts->commit_use_reference,
> +			 N_("use the 'reference' format to refer to commits")),
>  		OPT_END()
>  	};
>  	struct option *options = base_options;
> diff --git a/sequencer.c b/sequencer.c
> index a5f678f452..97abd5932b 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -221,6 +221,9 @@ static int git_sequencer_config(const char *k, const char *v, void *cb)
>  		return ret;
>  	}
>
> +	if (!strcmp(k, "revert.reference"))
> +		opts->commit_use_reference = git_config_bool(k, v);
> +
>  	status = git_gpg_config(k, v, NULL);
>  	if (status)
>  		return status;
> @@ -2059,6 +2062,20 @@ static int should_edit(struct replay_opts *opts) {
>  	return opts->edit;
>  }
>
> +static void refer_to_commit(struct replay_opts *opts,
> +			    struct strbuf *msgbuf, struct commit *commit)
> +{
> +	if (opts->commit_use_reference) {
> +		struct pretty_print_context ctx = {
> +			.abbrev = DEFAULT_ABBREV,
> +			.date_mode.type = DATE_SHORT,
> +		};
> +		format_commit_message(commit, "%h (%s, %ad)", msgbuf, &ctx);

It is somewhat sad that we have to semi-duplicate [*1*] this format here
and do not have something like an enum value we can use instead.

> +	} else {
> +		strbuf_addstr(msgbuf, oid_to_hex(&commit->object.oid));
> +	}
> +}
> +
>  static int do_pick_commit(struct repository *r,
>  			  struct todo_item *item,
>  			  struct replay_opts *opts,
> @@ -2167,14 +2184,19 @@ static int do_pick_commit(struct repository *r,
>  		base_label = msg.label;
>  		next = parent;
>  		next_label = msg.parent_label;
> -		strbuf_addstr(&msgbuf, "Revert \"");
> -		strbuf_addstr(&msgbuf, msg.subject);
> -		strbuf_addstr(&msgbuf, "\"\n\nThis reverts commit ");
> -		strbuf_addstr(&msgbuf, oid_to_hex(&commit->object.oid));
> +		if (!opts->commit_use_reference) {
> +			strbuf_addstr(&msgbuf, "Revert \"");
> +			strbuf_addstr(&msgbuf, msg.subject);
> +			strbuf_addstr(&msgbuf, "\"");
> +		} else {
> +			strbuf_addstr(&msgbuf, "DESCRIBE WHY WE ARE REVERTING HERE");
> +		}

We often tell newcomers that we prefer the shorter conditional block to
come first. Maybe you want to do that here, too? I don't mind the current
form, though.

> +		strbuf_addstr(&msgbuf, "\n\nThis reverts commit ");
> +		refer_to_commit(opts, &msgbuf, commit);
>
>  		if (commit->parents && commit->parents->next) {
>  			strbuf_addstr(&msgbuf, ", reversing\nchanges made to ");
> -			strbuf_addstr(&msgbuf, oid_to_hex(&parent->object.oid));
> +			refer_to_commit(opts, &msgbuf, parent);
>  		}
>  		strbuf_addstr(&msgbuf, ".\n");
>  	} else {
> diff --git a/sequencer.h b/sequencer.h
> index da64473636..698599fe4e 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -49,6 +49,7 @@ struct replay_opts {
>  	int reschedule_failed_exec;
>  	int committer_date_is_author_date;
>  	int ignore_date;
> +	int commit_use_reference;
>
>  	int mainline;
>
> diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
> index 8617efaaf1..36f9565b92 100755
> --- a/t/t3501-revert-cherry-pick.sh
> +++ b/t/t3501-revert-cherry-pick.sh
> @@ -159,6 +159,7 @@ test_expect_success 'cherry-pick works with dirty renamed file' '
>  '
>
>  test_expect_success 'advice from failed revert' '
> +	test_when_finished "git reset --hard" &&
>  	test_commit --no-tag "add dream" dream dream &&
>  	dream_oid=$(git rev-parse --short HEAD) &&
>  	cat <<-EOF >expected &&
> @@ -174,4 +175,34 @@ test_expect_success 'advice from failed revert' '
>  	test_must_fail git revert HEAD^ 2>actual &&
>  	test_cmp expected actual
>  '
> +
> +test_expect_success 'identification of reverted commit (vanilla)' '

It might make sense to replace "vanilla" by "default format".

> +	test_commit to-ident &&
> +	test_when_finished "git reset --hard to-ident" &&
> +	git checkout --detach to-ident &&
> +	git revert --no-edit HEAD &&
> +	git cat-file commit HEAD >actual.raw &&
> +	grep "^This reverts " actual.raw >actual &&
> +	echo "This reverts commit $(git rev-parse HEAD^)." >expect &&

I was a bit puzzled about this dance, as I had expected this instead:

	grep "^This reverts commit $(git rev-parse HEAD^)\\.$" actual.raw

but I guess you wanted to make sure that the file contents of `actual` are
shown if no match was found?

If that was the intention, we may want to add a test helper that I know
from other test frameworks, something like `test_contains` that takes a
regex and a file and prints out the full contents if no match was found.

It's obviously not necessary to add this test helper in this patch series
of a single patch ("separation of concerns"), just food for thought.

> +	test_cmp expect actual
> +'
> +
> +test_expect_success 'identification of reverted commit (reference)' '
> +	git checkout --detach to-ident &&
> +	git revert --reference --no-edit HEAD &&
> +	git cat-file commit HEAD >actual.raw &&
> +	grep "^This reverts " actual.raw >actual &&
> +	echo "This reverts commit $(git show -s --pretty=reference HEAD^)." >expect &&
> +	test_cmp expect actual
> +'

If it was up to me, I would combine these three test cases, if only to
help the `--run=<single-number>` case (the latter two depend on the side
effect of the first one to create a `to-ident` tag).

> +
> +test_expect_success 'identification of reverted commit (reference)' '
> +	git checkout --detach to-ident &&
> +	git -c revert.reference=true revert --no-edit HEAD &&
> +	git cat-file commit HEAD >actual.raw &&
> +	grep "^This reverts " actual.raw >actual &&
> +	echo "This reverts commit $(git show -s --pretty=reference HEAD^)." >expect &&
> +	test_cmp expect actual
> +'
> +
>  test_done
> --
> 2.36.1-298-g81715a4e6d

Looks good, I have no objections against merging this as-is.

Ciao,
Dscho

Footnote *1*: https://github.com/git/git/blob/v2.36.1/pretty.c#L103-L104
also has the `%C(auto)` prefix, which we obviously do not need here.

  reply	other threads:[~2022-05-23 13:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-22  4:32 [PATCH] revert: optionally refer to commit in the "reference" format Junio C Hamano
2022-05-23 13:25 ` Johannes Schindelin [this message]
2022-05-23 22:48   ` Junio C Hamano
2022-05-27  6:01     ` [PATCH v3] " Junio C Hamano
2022-05-30 16:40       ` Johannes Schindelin
2022-05-31 14:00       ` Phillip Wood
2022-06-01  4:45         ` Junio C Hamano
2022-06-01 15:03           ` Phillip Wood
2022-06-01 15:14       ` Ævar Arnfjörð Bjarmason
2022-06-01 21:52         ` Junio C Hamano
2022-05-30 16:50     ` Side effects in Git's test suite, was Re: [PATCH] " Johannes Schindelin
2022-05-31  8:03       ` Ævar Arnfjörð Bjarmason
2022-05-23 13:45 ` Ævar Arnfjörð Bjarmason
2022-05-23 22:37   ` Junio C Hamano
2022-05-24  8:12     ` Ævar Arnfjörð Bjarmason
2022-05-24 19:11       ` Junio C Hamano
2022-05-26 11:17 ` Phillip Wood
2022-05-26 17:29   ` Junio C Hamano
2022-06-26  9:29 ` René Scharfe
2022-06-27 15:38   ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2205231507350.352@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).