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.
next prev parent 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).