Git development
 help / color / mirror / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Stefan Näwe" <stefan.naewe@atlas-elektronik.com>,
	GitList <git@vger.kernel.org>
Subject: Re: [PATCH 0/6] Make 'git help everyday' work -> relnotes
Date: Wed, 22 Jan 2014 08:33:55 -0000	[thread overview]
Message-ID: <D97049A7BB5848B6ABA211DB7D941196@PhilipOakley> (raw)
In-Reply-To: xmqqbnz4svb7.fsf@gitster.dls.corp.google.com

From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> 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

Ah, no, it's not a script.

I had simply moved the content of the stalenotes section into its own 
file 'stalenotes.txt' which could then be included both within the 
git(1) section it came from, and a new release-notes(7) man page.

With that set up the Documentation/Makefile would generate the man 
pages, with their appropriate links, which can be accessed via the 'git 
help' command.

The big 'however' was that this would not actually include the latest 
release notes as literal text for immediate reading into the 
release-notes(7) man page, which would be my aim, and I think what 
Stefan had suggested as a preferred style.

>                      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...

My thought was that the latest release note would be included as literal 
text, as noted above.
Like you say, it may need to be a script, but I was being cautious about 
what extra work that would entail for each release.

>
>>
>> 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:
>

I hadn't looked back into that part of history. I was somehow expecting 
to see 'stalenotes' being defined somewhere in the current documenation 
preparation options, hence my question about when you would set 
'stalenotes'.

I'll have a look back at that to see how it was used back then.

>    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.
> 

  reply	other threads:[~2014-01-22  8:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 23:13 [PATCH 0/6] Make 'git help everyday' work Philip Oakley
2014-01-09 23:13 ` [PATCH 1/6] copy everyday.txt to giteveryday.txt Philip Oakley
2014-01-09 23:13 ` [PATCH 2/6] Update giteveryday.txt to fit man page formatting Philip Oakley
2014-01-09 23:13 ` [PATCH 3/6] add giteveryday to the manpages make list Philip Oakley
2014-01-09 23:13 ` [PATCH 4/6] Add deprecation note to old everyday.txt Philip Oakley
2014-01-09 23:13 ` [PATCH 5/6] add 'everyday' to the help --guides list Philip Oakley
2014-01-09 23:13 ` [PATCH 6/6] Update git(1) link to giteveryday Philip Oakley
2014-01-09 23:49 ` [PATCH 0/6] Make 'git help everyday' work Junio C Hamano
2014-01-10  8:06   ` Philip Oakley
2014-01-10 18:09     ` Junio C Hamano
2014-01-10 18:59       ` Philip Oakley
2014-01-11 19:50       ` Philip Oakley
2014-01-10  8:18   ` Stefan Näwe
2014-01-16 21:14     ` [PATCH 0/6] Make 'git help everyday' work -> relnotes Philip Oakley
2014-01-17 11:59       ` Stefan Näwe
2014-01-21 22:25         ` Philip Oakley
2014-01-21 23:28           ` Junio C Hamano
2014-01-22  0:22             ` Philip Oakley
2014-01-22  0:40               ` Junio C Hamano
2014-01-22  8:33                 ` Philip Oakley [this message]
2014-01-10 20:19 ` [PATCH 0/6] Make 'git help everyday' work Jonathan Nieder

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=D97049A7BB5848B6ABA211DB7D941196@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=stefan.naewe@atlas-elektronik.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