All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Stefan Beller <sbeller@google.com>
Subject: Re: [PATCH 0/7] migrate api-strbuf.txt into strbuf.h
Date: Thu, 12 Feb 2015 18:05:14 -0500	[thread overview]
Message-ID: <20150212230513.GA21222@peff.net> (raw)
In-Reply-To: <xmqqh9uqpwe9.fsf@gitster.dls.corp.google.com>

On Thu, Feb 12, 2015 at 03:01:18PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > This is a re-roll of this series:
> >
> >   http://thread.gmane.org/gmane.comp.version-control.git/260922/focus=261374
> >
> > from early December to move the strbuf documentation into the header
> > file.
> >
> > And of course the elephant in the room is the other dozen or more
> > api-*.txt files. I'd propose to do this strbuf.h series (and possible
> > follow-ons mentioned above) and stop there for a bit. That will let us
> > form a more coherent opinion on whether we like this system in practice,
> > how it ages as functions are changed and added, etc. That might affect
> > how or if we end up converting other files.
> >
> > It does leave us in an inconsistent state (some documentation is in
> > Documentation/technical, and some is in the headers), but I think that
> > is largely where we're at today. IMHO this is a strict improvement
> > because at least the logical chunk of "strbuf" is now in a single place.
> 
> Is there a general concensus on the direction?
> 
> I am inclined to merge this to 'next', if there is a general
> understanding that we will try to make the headers _the_ single
> source of truth of the API by (1) not adding to api-*.txt without
> describing new things in the headers and (2) moving things from
> api-*.txt to corresponding headers when clarifying, fixing or
> updating the API.

I'm fine with that (unsurprisingly), but I would like to hear an "OK"
from Jonathan before going ahead.

-Peff

  reply	other threads:[~2015-02-12 23:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16  9:02 [PATCH 0/7] migrate api-strbuf.txt into strbuf.h Jeff King
2015-01-16  9:04 ` [PATCH 1/7] strbuf.h: integrate api-strbuf.txt documentation Jeff King
2015-01-16  9:04 ` [PATCH 2/7] strbuf.h: unify documentation comments beginnings Jeff King
2015-01-16  9:05 ` [PATCH 3/7] strbuf.h: drop asciidoc list formatting from API docs Jeff King
2015-01-16  9:05 ` [PATCH 4/7] strbuf.h: format asciidoc code blocks as 4-space indent Jeff King
2015-01-16  9:05 ` [PATCH 5/7] strbuf.h: reorganize api function grouping headers Jeff King
2015-01-16  9:05 ` [PATCH 6/7] strbuf.h: drop boilerplate descriptions of strbuf_split_* Jeff King
2015-01-16  9:06 ` [PATCH 7/7] strbuf.h: group documentation for trim functions Jeff King
2015-02-12 23:01 ` [PATCH 0/7] migrate api-strbuf.txt into strbuf.h Junio C Hamano
2015-02-12 23:05   ` Jeff King [this message]
2015-02-16 22:41     ` Junio C Hamano
2015-02-17 23: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=20150212230513.GA21222@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --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.