From: Junio C Hamano <gitster@pobox.com>
To: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Cc: Linus Arver <linusa@google.com>,
Phillip Wood <phillip.wood123@gmail.com>,
git@vger.kernel.org, Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: [PATCH v2] sequencer: beautify subject of reverts of reverts
Date: Fri, 28 Jul 2023 08:10:42 -0700 [thread overview]
Message-ID: <xmqqpm4c5ax9.fsf@gitster.g> (raw)
In-Reply-To: <ZMOOQTMk2wFwtSfa@ugly> (Oswald Buddenhagen's message of "Fri, 28 Jul 2023 11:45:37 +0200")
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
> On Thu, Jul 27, 2023 at 10:26:01PM -0700, Linus Arver wrote:
>>How about introducing a suffix (+ or -) after the word "Revert" to
>>indicate the application/inclusion (+) or removal (-) of a commit?
>>
> i think that falls squarely into the "too nerdy" category, like the
> Revert^n proposal does.
True, but instead of dismissing it (or ^n) as "too nerdy", let's
compare it with what we are trying to achieve and see why we feel it
is not desirable. I think we are trying to find a good balance
between aesthetics and usefulness. The former should take lower
precedence, as it would be more subjective between the two.
The usefulness of the message comes from its information content.
What do we want to read out of these messages? I think we want
a title that immediately lets us know three things:
(1) What the original patch was about.
(2) What the final state is.
(3) How involved was the road to get to the final state has been.
As to (1), we are not proposing to lose what comes "Revert", so this
information is not lost under any proposal we have seen so far in
the discussion.
As to (2), with the current "Revert" -> "Revert Revert" -> "Revert
Revert Revert" -> ..., you have to count, which is cumbersome and
does not give you an immediate access to that information. With
"Revert^n", you'd see if n is even or odd to determine, which is
much better than the status quo, but it takes practice to interpret.
With "Revert" -> "Reapply" -> "Revert Reapply" -> "Reapply Reapply"
-> ..., the first word would give you the final state immediately.
We want to know (3), because between a change whose revert was
reverted and a change that hasn't been involved in any revert, there
may be no difference in the end result, the former is likely to be
trickier and merits more careful inspection than the latter. With
"Revert^n", we read how large the number n is to find the
information. With the current "the Revert repeated number of times"
or your "a pair of frontmost Reverts become one Reapply", the length
of the Revert/Reapply prefix conveys this information, but this is
associated with the cost of pushing the original title further to
the right and hard to read/find. Note that, while the number of
times revert-reapply sequence took place is a useful piece of
information, the exact number may not be all that important.
And from the above discussion, I wonder if the following would be a
good place to stop:
- The first revert is as before: Revert "original title"
- A revert of a revert becomes: Reapply "original title"
- A revert of a reapply becomes: Revert Reapply "original title"
- A revert of "Revert Reapply" becomes: Reapply Reapply "original title"
- A revert of "Reapply Reapply" becomes: Revert Reapply "original title"
In other words, we accept the fact that wedo not need exact number
of times reversions were done, and use that to simplify the output
to make sure we will not spend more than two words in the front of
the title. That would help to keep the original title visible,
while still allowing us to distinguish the ones that was reverted up
to four times (and "Revert Reapply" and "Reapply Reapply" only tell
us "final state is to (discard|accept) the original but it took us
_many_ times", without saying exactly how many).
next prev parent reply other threads:[~2023-07-28 15:10 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 8:35 [PATCH v2] sequencer: beautify subject of reverts of reverts Oswald Buddenhagen
2023-04-28 18:35 ` Junio C Hamano
2023-04-28 19:11 ` Oswald Buddenhagen
2023-05-01 16:44 ` Junio C Hamano
2023-05-01 19:10 ` Oswald Buddenhagen
2023-05-01 19:12 ` Junio C Hamano
2023-05-05 17:25 ` Junio C Hamano
2023-05-17 9:05 ` Phillip Wood
2023-05-17 10:00 ` Oswald Buddenhagen
2023-05-17 11:20 ` Phillip Wood
2023-05-17 17:02 ` Oswald Buddenhagen
2023-05-18 9:58 ` Phillip Wood
2023-05-18 16:28 ` Junio C Hamano
2023-07-28 5:26 ` Linus Arver
2023-07-28 9:45 ` Oswald Buddenhagen
2023-07-28 15:10 ` Junio C Hamano [this message]
2023-07-28 15:37 ` Oswald Buddenhagen
2023-07-28 16:31 ` Junio C Hamano
2023-07-28 16:47 ` Oswald Buddenhagen
2023-07-28 17:36 ` Linus Arver
2023-08-09 17:15 ` [PATCH v3 1/2] " Oswald Buddenhagen
2023-08-09 17:15 ` [PATCH v3 2/2] doc: revert: add discussion Oswald Buddenhagen
2023-08-10 21:50 ` Linus Arver
2023-08-10 22:00 ` Linus Arver
2023-08-11 15:10 ` Phillip Wood
2023-08-12 6:25 ` Oswald Buddenhagen
2023-08-13 22:09 ` Junio C Hamano
2023-08-14 14:13 ` Oswald Buddenhagen
2023-08-11 12:49 ` Oswald Buddenhagen
2023-08-11 23:00 ` Linus Arver
2023-08-12 7:19 ` Oswald Buddenhagen
2023-09-07 21:29 ` Linus Arver
2023-08-11 15:08 ` Phillip Wood
2023-08-11 17:10 ` Junio C Hamano
2023-08-11 17:05 ` Junio C Hamano
2023-08-11 17:44 ` Re* " Junio C Hamano
2023-08-11 17:53 ` Junio C Hamano
2023-08-11 17:56 ` rsbecker
2023-08-11 18:16 ` Eric Sunshine
2023-08-11 18:16 ` Oswald Buddenhagen
2023-08-11 19:43 ` Junio C Hamano
2023-08-11 15:05 ` [PATCH v3 1/2] sequencer: beautify subject of reverts of reverts Phillip Wood
2023-08-11 16:59 ` Junio C Hamano
2023-08-11 17:13 ` Oswald Buddenhagen
2023-08-21 17:07 ` [PATCH v4 " Oswald Buddenhagen
2023-08-21 17:07 ` [PATCH v4 2/2] git-revert.txt: add discussion Oswald Buddenhagen
2023-08-21 18:32 ` [PATCH v4 1/2] sequencer: beautify subject of reverts of reverts Junio C Hamano
2023-08-23 20:08 ` Taylor Blau
2023-08-23 21:38 ` Junio C Hamano
2023-08-24 6:14 ` Oswald Buddenhagen
2023-09-02 7:20 ` [PATCH v5] " Oswald Buddenhagen
2023-09-02 22:24 ` Junio C Hamano
2023-09-11 20:12 ` Kristoffer Haugsbakk
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=xmqqpm4c5ax9.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=linusa@google.com \
--cc=oswald.buddenhagen@gmx.de \
--cc=phillip.wood123@gmail.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.
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).