From: Heiko Voigt <hvoigt@hvoigt.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jens Lehmann <jens.lehmann@web.de>,
Jeff King <peff@peff.net>
Subject: [PATCH 0/4] allow more sources for config values
Date: Tue, 26 Feb 2013 20:30:50 +0100 [thread overview]
Message-ID: <20130226193050.GA22756@sandbox-ub> (raw)
In-Reply-To: <7v4nh13plo.fsf@alter.siamese.dyndns.org>
Hi,
On Sun, Feb 24, 2013 at 09:54:43PM -0800, Junio C Hamano wrote:
> The idea to allow more kinds of sources specified for "config_file"
> structure is not bad per-se, but whenever you design an enhancement
> to something that currently supports only on thing to allow taking
> another kind, please consider what needs to be done by the next
> person who adds the third kind. That would help catch design
> mistakes early. For example, will the "string-list" (I am not
> saying use of string-list makes sense as the third kind; just as an
> example off the top of my head) source patch add
>
> int is_string_list;
> struct string_list *string_list_contents;
>
> fields to this structure? Sounds insane for at least two reasons:
>
> * if both is_strbuf and is_string_list are true, what should
> happen?
>
> * is there a good reason to waste storage for the three fields your
> patch adds when sring_list strage (or FILE * storage for that
> matter) is used?
>
> The helper functions like config_fgetc() and config_ftell() sounds
> like you are going in the right direction but may want to do the
> OO-in-C in a similar way transport.c does, keeping a pointer to a
> structure of methods, but I didn't read the remainder of this patch
> very carefully enough to comment further.
I split up my config-from-strings patch from the "fetch moved submodules
on-demand" series[1] for nicer reviewability. Since Peff almost needed it
and the recursive submodule checkout will definitely[2] need it: How
about making it a seperate topic and implement this infrastructure
first?
Junio I incorporated your comments this seems like a result ready for
inclusion.
[1] http://article.gmane.org/gmane.comp.version-control.git/217018
[2] http://article.gmane.org/gmane.comp.version-control.git/217155
Heiko Voigt (4):
config: factor out config file stack management
config: drop file pointer validity check in get_next_char()
config: make parsing stack struct independent from actual data source
teach config parsing to read from strbuf
.gitignore | 1 +
Makefile | 1 +
cache.h | 1 +
config.c | 140 ++++++++++++++++++++++++++++++++++++++-----------
t/t1300-repo-config.sh | 4 ++
test-config.c | 41 +++++++++++++++
6 files changed, 158 insertions(+), 30 deletions(-)
create mode 100644 test-config.c
--
1.8.2.rc0.26.gf7384c5
next prev parent reply other threads:[~2013-02-26 19:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-25 1:02 [RFC/WIP PATCH 0/3] fetch moved submodules on-demand Heiko Voigt
2013-02-25 1:04 ` [RFC/WIP PATCH 1/3] teach config parsing to read from strbuf Heiko Voigt
2013-02-25 5:54 ` Junio C Hamano
2013-02-25 17:29 ` Heiko Voigt
2013-02-26 19:30 ` Heiko Voigt [this message]
2013-02-26 19:38 ` [PATCH 1/4] config: factor out config file stack management Heiko Voigt
2013-02-26 19:54 ` Jeff King
2013-02-26 20:09 ` Heiko Voigt
2013-02-26 20:15 ` Jeff King
2013-02-26 22:10 ` Junio C Hamano
2013-02-27 7:51 ` Heiko Voigt
2013-02-26 22:12 ` Junio C Hamano
2013-02-27 7:56 ` Heiko Voigt
2013-02-26 19:40 ` [PATCH 2/4] config: drop file pointer validity check in get_next_char() Heiko Voigt
2013-02-26 20:05 ` Jeff King
2013-02-27 7:52 ` Heiko Voigt
2013-02-28 0:42 ` Heiko Voigt
2013-02-28 0:54 ` Heiko Voigt
2013-02-26 19:42 ` [PATCH 3/4] config: make parsing stack struct independent from actual data source Heiko Voigt
2013-02-26 19:43 ` [PATCH 4/4] teach config parsing to read from strbuf Heiko Voigt
2013-03-07 18:42 ` Ramsay Jones
2013-03-10 16:39 ` Heiko Voigt
2013-02-26 4:55 ` [RFC/WIP PATCH 1/3] " Jeff King
2013-02-25 1:05 ` [RFC/WIP PATCH 2/3] implement fetching of moved submodules Heiko Voigt
2013-02-25 1:06 ` [RFC/WIP PATCH 3/3] submodule: simplify decision tree whether to or not to fetch Heiko Voigt
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=20130226193050.GA22756@sandbox-ub \
--to=hvoigt@hvoigt.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jens.lehmann@web.de \
--cc=peff@peff.net \
/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.