git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2] sequencer: beautify subject of reverts of reverts

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 28, 2023, 15:10 UTC
Message-ID
<xmqqpm4c5ax9.fsf@gitster.g>
In-Reply-To
<ZMOOQTMk2wFwtSfa@ugly>
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
Show 6 quoted lines
> 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).

Previous: Oswald BuddenhagenNext: Oswald Buddenhagen
Message 16 of 53 in “sequencer: beautify subject of reverts of reverts”
  1. sequencer: beautify subject of reverts of revertsOswald Buddenhagen, Apr 28, 2023
  2. Junio C HamanoApr 28, 2023
  3. Oswald BuddenhagenApr 28, 2023
  4. Junio C HamanoMay 1, 2023
  5. Oswald BuddenhagenMay 1, 2023
  6. Junio C HamanoMay 1, 2023
  7. Junio C HamanoMay 5, 2023
  8. Phillip WoodMay 17, 2023
  9. Oswald BuddenhagenMay 17, 2023
  10. Phillip WoodMay 17, 2023
  11. Oswald BuddenhagenMay 17, 2023
  12. Phillip WoodMay 18, 2023
  13. Junio C HamanoMay 18, 2023
  14. Linus ArverJul 28, 2023
  15. Oswald BuddenhagenJul 28, 2023
  16. Junio C HamanoJul 28, 2023
  17. Oswald BuddenhagenJul 28, 2023
  18. Junio C HamanoJul 28, 2023
  19. Oswald BuddenhagenJul 28, 2023
  20. Linus ArverJul 28, 2023
  21. 1/2 sequencer: beautify subject of reverts of revertsOswald Buddenhagen, Aug 9, 2023
  22. 2/2 doc: revert: add discussionOswald Buddenhagen, Aug 9, 2023
  23. Linus ArverAug 10, 2023
  24. Linus ArverAug 10, 2023
  25. Oswald BuddenhagenAug 11, 2023
  26. Linus ArverAug 11, 2023
  27. Oswald BuddenhagenAug 12, 2023
  28. Linus ArverSep 7, 2023
  29. Phillip WoodAug 11, 2023
  30. Oswald BuddenhagenAug 12, 2023
  31. Junio C HamanoAug 13, 2023
  32. Oswald BuddenhagenAug 14, 2023
  33. Phillip WoodAug 11, 2023
  34. Junio C HamanoAug 11, 2023
  35. Junio C HamanoAug 11, 2023
  36. Re* [PATCH v3 2/2] doc: revert: add discussionJunio C Hamano, Aug 11, 2023
  37. Junio C HamanoAug 11, 2023
  38. rsbecker@nexbridge.comAug 11, 2023
  39. Eric SunshineAug 11, 2023
  40. Oswald BuddenhagenAug 11, 2023
  41. Junio C HamanoAug 11, 2023
  42. Phillip WoodAug 11, 2023
  43. Junio C HamanoAug 11, 2023
  44. Oswald BuddenhagenAug 11, 2023
  45. 1/2 sequencer: beautify subject of reverts of revertsOswald Buddenhagen, Aug 21, 2023
  46. 2/2 git-revert.txt: add discussionOswald Buddenhagen, Aug 21, 2023
  47. Junio C HamanoAug 21, 2023
  48. Taylor BlauAug 23, 2023
  49. Junio C HamanoAug 23, 2023
  50. Oswald BuddenhagenAug 24, 2023
  51. sequencer: beautify subject of reverts of revertsOswald Buddenhagen, Sep 2, 2023
  52. Junio C HamanoSep 2, 2023
  53. Kristoffer HaugsbakkSep 11, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.