From: Heiko Voigt <hvoigt@hvoigt.net>
To: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Jens Lehmann <jens.lehmann@web.de>,
Jeff King <peff@peff.net>
Subject: Re: [PATCH 4/4] teach config parsing to read from strbuf
Date: Sun, 10 Mar 2013 17:39:34 +0100 [thread overview]
Message-ID: <20130310163933.GA26857@sandbox-ub.fritz.box> (raw)
In-Reply-To: <5138DFA3.8040308@ramsay1.demon.co.uk>
Hi,
On Thu, Mar 07, 2013 at 06:42:43PM +0000, Ramsay Jones wrote:
> Heiko Voigt wrote:
> > +int git_config_from_strbuf(config_fn_t fn, struct strbuf *strbuf, void *data)
> > +{
> > + struct config top;
> > + struct config_strbuf str;
> > +
> > + str.strbuf = strbuf;
> > + str.pos = 0;
> > +
> > + top.data = &str;
>
> You will definitely want to initialise 'top.name' here, rather
> than let it take whatever value happens to be at that position
> on the stack. In your editor, search for 'cf->name' and contemplate
> each such occurrence.
Good catch, thanks. The initialization seems to got lost during
refactoring. In the codepaths we call with the new strbuf function it is
only used for error reporting so I think we need to get the name from
the user of this function so the error messages are useful.
I have extended the test to demonstrate how I imagine this name could
look like.
> Does the 'include' facility work from a strbuf? Should it?
No the 'include' facility does not work here. A special handling would
need to be implemented by the caller. For us 'include' values have no
special meaning and are parsed like normal values.
AFAICS when a config file is given to git config we do not currently
respect includes. So we can just do the same behavior here for the
moment. There is no roadblock against adding it later.
> Are you happy with the error handling/reporting?
Good point, while adding the name for strbuf I noticed that we currently
die on some parsing errors. We should probably make these errors
handleable for strbufs. Currently the main usecase is to read submodule
configurations from the database and in case someone commits a broken
configuration we should be able to continue with that. Otherwise the
repository might render into an unuseable state. I will look into that.
> Do the above additions to the test-suite give you confidence
> that the code works as you intend?
Well, I am reusing most of the existing infrastructure which I assume is
tested using config files. So what I want to test here is the
integration of this new function. As you mentioned the name variable I
have now added a test for the parsing error case as well. I have
refactored the test binary to read configs from stdin so its easiert to
implement further tests from the bash part of the testsuite.
I will send out another iteration shortly.
Cheers Heiko
next prev parent reply other threads:[~2013-03-10 16:40 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 ` [PATCH 0/4] allow more sources for config values Heiko Voigt
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 [this message]
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=20130310163933.GA26857@sandbox-ub.fritz.box \
--to=hvoigt@hvoigt.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jens.lehmann@web.de \
--cc=peff@peff.net \
--cc=ramsay@ramsay1.demon.co.uk \
/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 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 NNTP newsgroup(s).