From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
Jeff King <peff@peff.net>, Stefan Beller <sbeller@google.com>,
"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] document string_list_clear
Date: Wed, 10 Dec 2014 15:04:41 -0800 [thread overview]
Message-ID: <xmqq61djf6nq.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20141210223721.GG16345@google.com> (Jonathan Nieder's message of "Wed, 10 Dec 2014 14:37:21 -0800")
Jonathan Nieder <jrnieder@gmail.com> writes:
> Some possibilities, in order of my preference (earlier items are better):
>
> 1. Move documentation to header and provide a program to generate a nice
> standalone document.
>
> 2. Move documentation to header, being careful enough that the header
> sort of works as a standalone document.
>
> 3. Move documentation to Documentation/technical/ and keep the header
> bare-bones.
>
> 4. Status quo (comprehensive documentation for some functions in both
> places, for others in only one place, no reliable way for someone
> to find the information they need in one place).
>
> Since (3) is better than (4), I wrote simple patches to do that for
> strbuf.h and string-list.h. I meant them in earnest --- I hope they
> get applied.
>
> I think peff was working on (2), which is an admirable goal. The
> patch seemed to be incomplete.
Yeah, I agree with the above preferred ordering, and also think once
we get to (2) it would be "usable" by the intended audience. Those
who prefer (1) over (2) are the ones who somehow want to read hard
copies ;-) and are likely to be different audiences and are better
served by people with different skill-set and inclination.
I am not sure if (2) and (3) are that incompatible, though. If you
had an acceptable version of (3), wouldn't it be just the matter of
indenting the whole thing with "s/^/ */", sprinkle "/**" and "*/" at
strategic paragraph breaks, and move them back to the corresponding
header?
next prev parent reply other threads:[~2014-12-10 23:04 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-06 1:51 [PATCH] document string_list_clear Stefan Beller
2014-12-06 2:04 ` Jonathan Nieder
2014-12-06 5:27 ` Jeff King
2014-12-06 5:30 ` Jeff King
2014-12-09 19:41 ` Junio C Hamano
2014-12-09 20:15 ` Jeff King
2014-12-09 20:21 ` Jonathan Nieder
2014-12-09 19:37 ` Junio C Hamano
2014-12-09 19:48 ` Stefan Beller
2014-12-09 20:17 ` Jonathan Nieder
2014-12-09 20:27 ` Jeff King
2014-12-09 20:32 ` Stefan Beller
2014-12-09 20:46 ` Jeff King
2014-12-09 22:23 ` Jonathan Nieder
2014-12-09 23:18 ` Junio C Hamano
2014-12-10 8:52 ` Jeff King
2014-12-10 8:43 ` Jeff King
2014-12-10 9:18 ` Jonathan Nieder
2014-12-12 9:16 ` Jeff King
2014-12-12 18:31 ` Jonathan Nieder
2014-12-12 19:17 ` Junio C Hamano
2014-12-12 19:19 ` Stefan Beller
2014-12-12 19:29 ` Jeff King
2014-12-12 19:24 ` Jeff King
2014-12-12 19:35 ` Jonathan Nieder
2014-12-12 21:27 ` Jeff King
2014-12-12 21:28 ` [PATCH 1/4] strbuf: migrate api-strbuf.txt documentation to strbuf.h Jeff King
2014-12-12 21:40 ` Jeff King
2014-12-12 22:16 ` Junio C Hamano
2014-12-12 22:30 ` Jonathan Nieder
2014-12-12 21:28 ` [PATCH 2/4] strbuf.h: drop asciidoc list formatting from API docs Jeff King
2014-12-12 22:19 ` Junio C Hamano
2014-12-12 22:37 ` Jonathan Nieder
2014-12-12 21:30 ` [PATCH 3/4] strbuf.h: format asciidoc code blocks as 4-space indent Jeff King
2014-12-12 22:39 ` Jonathan Nieder
2014-12-14 17:42 ` Michael Haggerty
2014-12-12 21:32 ` [PATCH 4/4] strbuf.h: reorganize api function grouping headers Jeff King
2014-12-12 22:46 ` Jonathan Nieder
2014-12-12 22:32 ` [PATCH] document string_list_clear Stefan Beller
2014-12-10 20:09 ` Michael Haggerty
2014-12-10 21:51 ` Jonathan Nieder
2014-12-10 22:28 ` Junio C Hamano
2014-12-10 22:37 ` Jonathan Nieder
2014-12-10 23:04 ` Junio C Hamano [this message]
2014-12-10 23:08 ` Jonathan Nieder
2014-12-09 22:49 ` Jonathan Nieder
2014-12-09 23:07 ` Stefan Beller
2014-12-09 23:15 ` Jonathan Nieder
2014-12-09 20:00 ` 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=xmqq61djf6nq.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
--cc=sbeller@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.