git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

  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

  List information: http://vger.kernel.org/majordomo-info.html

* 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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).