From: "Junio C Hamano" <gits...@pobox.com>
"Philip Oakley" <philipoak...@iee.org> writes:
Determining which is the current release note is possibly more
problematic, which should be when making the documentation.
Hmmm.... Why?
You are already aware of the stale-notes section, no? Isn't the top
one the latest?
It's that the 'git help release-notes' would _include_ the latest
release notes, not just link to them (which is what the stalenotes
currently does). Or at least that was the idea.
Trying to determine the latest version, and then include those release
notes, and the subsequent maint notes, into the putative
"release-notes(7)" man page, without causing you any maintenance hassle,
was the conceptual problem.
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.
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.
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
