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

Re: [PATCH v5 11/12] doc: revisions: show revision expansion in examples

From
Philip Oakley <philipoakley@iee.org>
Date
Aug 12, 2016, 22:45 UTC
Message-ID
<7765A995ADF6470DBA99D000AF7B5538@PhilipOakley>
In-Reply-To
<f418c41b-f590-0b6a-236a-c109a7296434@xiplink.com>
From: "Marc Branchaud" <marcnarc@xiplink.com>
Show 31 quoted lines
> On 2016-08-12 03:07 AM, Philip Oakley wrote:
>> The revisions examples show the revison arguments and the selected
>> commits, but do not show the intermediate step of the expansion of
>> the special 'range' notations. Extend the examples, including an
>> all-parents multi-parent merge commit example.
>>
>> Sort the examples and fix the alignment for those unaffected
>> in the next commit.
>>
>> Signed-off-by: Philip Oakley <philipoakley@iee.org>
>> ---
>> new
>> Cc: Jakub Narębski <jnareb@gmail.com>
>> ---
>>  Documentation/revisions.txt | 19 +++++++++++++------
>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
>> index 70864d5..ac7dd8e 100644
>> --- a/Documentation/revisions.txt
>> +++ b/Documentation/revisions.txt
>> @@ -326,16 +326,23 @@ Revision Range Summary
>>    as giving commit '<rev>' and then all its parents prefixed with
>>    '{caret}' to exclude them (and their ancestors).
>>
>> -Here are a handful of examples:
>> +Here are a handful of examples using the Loeliger illustration above:
>>
>> +   Args   Expansion       Selection
>
> I think "Result" would be better than "Selection" here.

I wanted to avoid that. I feel that "Result" is too general. I had thought about using the 'ed' rather than 'ion' word endings, but that would require (to my mind) the noun e.g. "Expanded arguments" and " Selected commits" (still could be - see below), while the 'ion' endings felt complete. The Result is what is shown in thable below these headings ;-)

>
> Also, shouldn't all the ^ in these examples be {caret}?  (I likely just 
> don't understand the rationale for using {caret} in some places and ^ in 
> others...)

All the conversions appear to work. I think that asciidoc is viewing these a blocked text without any expansion. Plus, it would be horrendous trying to check the formatting (endless reruns of make.. ... .. )

Show 19 quoted lines
>
>>     D                G H D
>>     D F              G H I J D F
>>     ^G D             H D
>>     ^D B             E I J F B
>> -   B..C             C
>> -   B...C            G H D E B C
>> +   B..C   = ^B C          C
>> +   B...C  = B ^F C        G H D E B C
>>     ^D B C           E I J F B C
>>     C                I J F C
>> -   C^@              I J F
>> -   C^!              C
>> -   F^! D            G H D F
>> +   C^@    = C^1
>
> I have a mixed reaction to showing this "C^1" expansion, and the "B^1 B^2 
> B^3" one as well.  I see the appeal of showing the parent notation, but 
> really that was already explained to death in the first section.

This was the whole point. For some (e.g. me) the explanations had fallen flat on their face, and it was difficult to see what it was on about. Now I know, it's all obvious, but what was needed was a carefully stepped through example or two. If the dear reader can't see the big steps, let's give them small steps.

Jacob had given an 'example' in response to my early query, but it just felt like repetion of what had already been said, but it didn't take the next [small] step, which this example does (partly because it can as it can use the Loeliger diagram, which wasn't available in Jacob's example).

I also deliberately added the B^@ and B^! (standalone) example as the C^@ and C^! didn't have an 'all parents' (plurals!), but it did have the indentation issue - see above about stretching out the headers, which would give more space for the indentations.

Show 9 quoted lines
> Here it's distracting.  I think it's clearer for the reader to remove 
> these expansions and just use the node names from the illustration.
>
>> +          = F             I J F
>> +   B^@    = B^1 B^2 B^3
>> +          = D E F         D G H E F I J
>> +   C^!    = C ^C^1
>
> I think this expansion might be better expressed as "C ^C^@".
I hadn't viewed it that way. It would be an extra step.
Show 16 quoted lines
>        It'll be the same for "B^! = B ^B^@" as well, which demonstrates a 
> nice consistency and also helps to emphasize the meaning of the ^@ 
> notation.
>
>> +          = C ^F          C
>> +   B^! = B ^B^1 ^B^2 ^B^3
>> +       = B ^D ^E ^F       B
>
> The layout of these last two lines doesn't match the others.  They should 
> be:
>
>    B^!    = B ^B^1 ^B^2   ^B^3
>           = B ^D ^E ^F    B
>
> I see that the next patch fixes the layout of the unchanged examples, but 
> it leaves these two unaligned.

As noted it was about squeezing that one in. I'll look at alternate heading titles and spacing options.

-- Philip

Previous: Marc BranchaudNext: Philip Oakley
Message 86 of 107 in “name for A..B ranges?”
  1. Philip OakleyJun 22, 2016
  2. Jeff KingJun 24, 2016
  3. Junio C HamanoJun 24, 2016
  4. Philip OakleyJun 25, 2016
  5. 0/2 Re: name for A..B ranges?Philip Oakley, Jun 25, 2016
  6. 2/2 doc: give headings for the two and three dot notationsPhilip Oakley, Jun 25, 2016
  7. 1/2 doc: use 'symmetric difference' consistentlyPhilip Oakley, Jun 25, 2016
  8. doc: show the actual left, right, and boundary marksPhilip Oakley, Jun 25, 2016
  9. 0/4 Name for A..B ranges?Philip Oakley, Jun 30, 2016
  10. 1/4 doc: use 'symmetric difference' consistentlyPhilip Oakley, Jun 30, 2016
  11. 3/4 doc: give headings for the two and three dot notationsPhilip Oakley, Jun 30, 2016
  12. 4/4 doc: clarify that `^r1` will exclude `r1` itselfPhilip Oakley, Jun 30, 2016
  13. Junio C HamanoJul 1, 2016
  14. Philip OakleyJul 1, 2016
  15. Junio C HamanoJul 1, 2016
  16. Junio C HamanoJul 1, 2016
  17. Philip OakleyJul 10, 2016
  18. 2/4 doc: show the actual left, right, and boundary marksPhilip Oakley, Jun 30, 2016
  19. Junio C HamanoJul 1, 2016
  20. 0/8 Name for A..B ranges?Philip Oakley, Jul 11, 2016
  21. 1/8 doc: use 'symmetric difference' consistentlyPhilip Oakley, Jul 11, 2016
  22. 3/8 doc: show the actual left, right, and boundary marksPhilip Oakley, Jul 11, 2016
  23. 4/8 doc: give headings for the two and three dot notationsPhilip Oakley, Jul 11, 2016
  24. Marc BranchaudJul 12, 2016
  25. Junio C HamanoJul 12, 2016
  26. Philip OakleyJul 12, 2016
  27. Jakub NarębskiJul 19, 2016
  28. Philip OakleyJul 19, 2016
  29. Philip OakleyJul 12, 2016
  30. Jeff KingJul 12, 2016
  31. 5/8 doc: gitrevisions - use 'reachable' in page descriptionPhilip Oakley, Jul 11, 2016
  32. 6/8 doc: gitrevisions - clarify 'latter case' is revision walkPhilip Oakley, Jul 11, 2016
  33. 7/8 doc: revisions - define `reachable`Philip Oakley, Jul 11, 2016
  34. Marc BranchaudJul 12, 2016
  35. Philip OakleyJul 12, 2016
  36. 8/8 doc: revisions - clarify reachability examplesPhilip Oakley, Jul 11, 2016
  37. 2/8 doc: revisions - name the Left and Right sidesPhilip Oakley, Jul 11, 2016
  38. Junio C HamanoJul 12, 2016
  39. Philip OakleyJul 12, 2016
  40. Junio C HamanoJul 12, 2016
  41. Philip OakleyJul 12, 2016
  42. 0/8 Name for A..B ranges?Philip Oakley, Jul 20, 2016
  43. 2/8 doc: revisions - name the left and right sidesPhilip Oakley, Jul 20, 2016
  44. 7/8 doc: revisions - define `reachable`Philip Oakley, Jul 20, 2016
  45. 8/8 doc: revisions - clarify reachability examplesPhilip Oakley, Jul 20, 2016
  46. 6/8 doc: gitrevisions - clarify 'latter case' is revision walkPhilip Oakley, Jul 20, 2016
  47. 3/8 doc: show the actual left, right, and boundary marksPhilip Oakley, Jul 20, 2016
  48. 1/8 doc: use 'symmetric difference' consistentlyPhilip Oakley, Jul 20, 2016
  49. 5/8 doc: gitrevisions - use 'reachable' in page descriptionPhilip Oakley, Jul 20, 2016
  50. 4/8 doc: give headings for the two and three dot notationsPhilip Oakley, Jul 20, 2016
  51. Marc BranchaudJul 21, 2016
  52. Philip OakleyJul 21, 2016
  53. Marc BranchaudJul 21, 2016
  54. Junio C HamanoJul 22, 2016
  55. Junio C HamanoJul 20, 2016
  56. 00/12 Update git revisionsPhilip Oakley, Aug 11, 2016
  57. 01/12 doc: use 'symmetric difference' consistentlyPhilip Oakley, Aug 11, 2016
  58. Jakub NarębskiAug 26, 2016
  59. Junio C HamanoAug 26, 2016
  60. Philip OakleyAug 11, 2016
  61. 00/12 Update git revisionsPhilip Oakley, Aug 12, 2016
  62. 06/12 doc: revisions: single vs multi-parent notation comparisonPhilip Oakley, Aug 12, 2016
  63. Jakub NarębskiAug 26, 2016
  64. Junio C HamanoAug 26, 2016
  65. 12/12 doc: revisions: sort examples and fix alignment of the unchangedPhilip Oakley, Aug 12, 2016
  66. 11/12 doc: revisions: show revision expansion in examplesPhilip Oakley, Aug 12, 2016
  67. 05/12 doc: revisions: extra clarification of <rev>^! notation effectsPhilip Oakley, Aug 12, 2016
  68. Marc BranchaudAug 15, 2016
  69. Philip OakleyAug 15, 2016
  70. BUG: indent-with-non-tab always on (was: Re: [PATCH v6 00/12] Update git revisions)Marc Branchaud, Aug 15, 2016
  71. Marc BranchaudAug 15, 2016
  72. Junio C HamanoAug 15, 2016
  73. Junio C HamanoAug 31, 2016
  74. 00/12 Update git revisionsPhilip Oakley, Aug 11, 2016
  75. 01/12 doc: use 'symmetric difference' consistentlyPhilip Oakley, Aug 11, 2016
  76. 00/12 Update git revisionsPhilip Oakley, Aug 12, 2016
  77. 12/12 doc: revisions: sort examples and fix alignment of the unchangedPhilip Oakley, Aug 12, 2016
  78. 09/12 doc: revisions - define `reachable`Philip Oakley, Aug 12, 2016
  79. Jakub NarębskiAug 28, 2016
  80. Philip OakleyAug 29, 2016
  81. Jakub NarębskiAug 29, 2016
  82. Philip OakleyAug 29, 2016
  83. 08/12 doc: gitrevisions - clarify 'latter case' is revision walkPhilip Oakley, Aug 12, 2016
  84. 11/12 doc: revisions: show revision expansion in examplesPhilip Oakley, Aug 12, 2016
  85. Marc BranchaudAug 12, 2016
  86. Philip OakleyAug 12, 2016
  87. 06/12 doc: revisions: single vs multi-parent notation comparisonPhilip Oakley, Aug 12, 2016
  88. Marc BranchaudAug 12, 2016
  89. Philip OakleyAug 12, 2016
  90. 10/12 doc: revisions - clarify reachability examplesPhilip Oakley, Aug 12, 2016
  91. 05/12 doc: revisions: extra clarification of <rev>^! notation effectsPhilip Oakley, Aug 12, 2016
  92. Marc BranchaudAug 12, 2016
  93. Philip OakleyAug 12, 2016
  94. 03/12 doc: show the actual left, right, and boundary marksPhilip Oakley, Aug 12, 2016
  95. 01/12 doc: use 'symmetric difference' consistentlyPhilip Oakley, Aug 12, 2016
  96. 07/12 doc: gitrevisions - use 'reachable' in page descriptionPhilip Oakley, Aug 12, 2016
  97. 04/12 doc: revisions: give headings for the two and three dot notationsPhilip Oakley, Aug 12, 2016
  98. Jeff KingAug 12, 2016
  99. Marc BranchaudAug 12, 2016
  100. 02/12 doc: revisions - name the left and right sidesPhilip Oakley, Aug 12, 2016
  101. Marc BranchaudAug 12, 2016
  102. Philip OakleyAug 12, 2016
  103. Junio C HamanoAug 12, 2016
  104. Junio C HamanoJun 25, 2016
  105. Philip OakleyJun 27, 2016
  106. Junio C HamanoJun 27, 2016
  107. Philip OakleyJun 27, 2016

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.