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

Re: [PATCH 0/6] Make 'git help everyday' work -> relnotes

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 22, 2014, 00:40 UTC
Message-ID
<xmqqbnz4svb7.fsf@gitster.dls.corp.google.com>
In-Reply-To
<2D10AF8E0C024CC5A817528582FDE07D@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
Show 5 quoted lines
> I already have a local patch that creates a stalenote.txt file, and
> includes that in a "release-notes(7)" man page, but it still leaves
> the actual release notes in a separate plain text file, linked from
> the man page, rather than being right at hand, which is what I think
> readers would expect.

Sorry, but I still do not get it. If you have a script that reads git.txt and extracts its stale-notes section to generate the source to be processed into release-notes(7), why can't that script also include the contents of the latest release notes inline into its output?

My release notes are _not_ written to be compatible with/processable by AsciiDoc (they are meant to be mere plain text)---perhaps you are wondering if that would make it harder to maintain your script that produces release-notes.txt?

Confused...
Show 5 quoted lines
>
> My other question would be to ask how you normally manage the up-issue
> of the stalenotes, and when you would normally create that section in
> git(1) as I didn't see any ifdef::stalenotes[] being defined anywhere
> else.

I'm not sure if I am understanding the question right (up-issue?), but it used to be that the preformatted and web-reachable manual pages at k.org were processed with stalenotes defined (which by the way was disabled with adaa3caf "Meta/dodoc.sh: adjust to the new layout, 2011-11-15" on the todo branch), and 26cfcfbf "Add release notes to the distribution., 2007-02-13" used that facility to prepare something like this:

    docs/git.html
        /git-cat-file.html
        ...
    docs/vX.Y.Z/git.html
    docs/vX.Y.Z/git-cat-file.html
                ...

where the "latest" one lived immediately underneath docs/*, while older ones were in versioned subdirectories.

Previous: Philip OakleyNext: Philip Oakley
Message 19 of 21 in “Make 'git help everyday' work”
  1. 0/6 Make 'git help everyday' workPhilip Oakley, Jan 9, 2014
  2. 1/6 copy everyday.txt to giteveryday.txtPhilip Oakley, Jan 9, 2014
  3. 2/6 Update giteveryday.txt to fit man page formattingPhilip Oakley, Jan 9, 2014
  4. 3/6 add giteveryday to the manpages make listPhilip Oakley, Jan 9, 2014
  5. 4/6 Add deprecation note to old everyday.txtPhilip Oakley, Jan 9, 2014
  6. 5/6 add 'everyday' to the help --guides listPhilip Oakley, Jan 9, 2014
  7. 6/6 Update git(1) link to giteverydayPhilip Oakley, Jan 9, 2014
  8. Junio C HamanoJan 9, 2014
  9. Philip OakleyJan 10, 2014
  10. Junio C HamanoJan 10, 2014
  11. Philip OakleyJan 10, 2014
  12. Philip OakleyJan 11, 2014
  13. Stefan NäweJan 10, 2014
  14. Philip OakleyJan 16, 2014
  15. Stefan NäweJan 17, 2014
  16. Philip OakleyJan 21, 2014
  17. Junio C HamanoJan 21, 2014
  18. Philip OakleyJan 22, 2014
  19. Junio C HamanoJan 22, 2014
  20. Philip OakleyJan 22, 2014
  21. Jonathan NiederJan 10, 2014

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.