All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Turner <dturner@twopensource.com>
To: Jeff King <peff@peff.net>
Cc: git mailing list <git@vger.kernel.org>,
	mhagger@alum.mit.edu, Duy Nguyen <pclouds@gmail.com>
Subject: Re: [PATCH 06/10] setup: refactor repo format reading and verification
Date: Tue, 01 Mar 2016 16:20:06 -0500	[thread overview]
Message-ID: <1456867206.18017.94.camel@twopensource.com> (raw)
In-Reply-To: <20160301144206.GF12887@sigill.intra.peff.net>

On Tue, 2016-03-01 at 09:42 -0500, Jeff King wrote:
> +/*
> + * Read the repository format characteristics from the config file
> "path". If
> + * the version cannot be extracted from the file for any reason, the
> version
> + * field will be set to -1, and all other fields are undefined.
> + */
> +void read_repository_format(struct repository_format *format, const
> char *path);

Generally speaking, I don't care for this interface; I would prefer to
return -1 and not change the struct.  But I see why it's maybe simpler
in this one case.

+/*
> + * Internally, we need to swap out "fn" here, but we don't want to
> expose
> + * that to the world. Hence a wrapper around this internal function.
> + */

I don't understand this comment.  fn is not being swapped out -- it's
being passed on directly.  

> +static void read_repository_format_1(struct repository_format
> *format,
> +				     config_fn_t fn, const char
> *path)

The argument order here is different from git_config_from_file -- is
that for a reason?

> +	if (format->version >= 1 && format->unknown_extensions.nr) {
> +		int i;
> +
> +		for (i = 0; i < format->unknown_extensions.nr; i++)
> +			strbuf_addf(err, "unknown repository
> extension: %s",
> +				    format
> ->unknown_extensions.items[i].string);

newline here or something?  Otherwise multiple unknown extensions will
get jammed together.

  reply	other threads:[~2016-03-01 21:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01 14:35 [PATCH 0/10] cleaning up check_repository_format_gently Jeff King
2016-03-01 14:37 ` [PATCH 01/10] setup: document check_repository_format() Jeff King
2016-03-01 14:38 ` [PATCH 02/10] wrap shared_repository global in get/set accessors Jeff King
2016-03-01 14:39 ` [PATCH 03/10] lazily load core.sharedrepository Jeff King
2016-03-03 13:00   ` Duy Nguyen
2016-03-03 18:23     ` Jeff King
2016-03-01 14:40 ` [PATCH 04/10] check_repository_format_gently: stop using git_config_early Jeff King
2016-03-03 13:08   ` Duy Nguyen
2016-03-03 18:27     ` Jeff King
2016-03-01 14:40 ` [PATCH 05/10] config: drop git_config_early Jeff King
2016-03-01 14:42 ` [PATCH 06/10] setup: refactor repo format reading and verification Jeff King
2016-03-01 21:20   ` David Turner [this message]
2016-03-02  2:51     ` Jeff King
2016-03-03 13:19   ` Duy Nguyen
2016-03-03 18:28     ` Jeff King
2016-03-01 14:43 ` [PATCH 07/10] init: use setup.c's repo version verification Jeff King
2016-03-01 14:45 ` [PATCH 08/10] setup: unify repository version callbacks Jeff King
2016-03-01 14:45 ` [PATCH 09/10] setup: drop repository_format_version global Jeff King
2016-03-01 14:45 ` [PATCH 10/10] setup: drop GIT_REPO_VERSION constants Jeff King
2016-03-02  0:13   ` David Turner
2016-03-02  2:52     ` Jeff King
2016-03-02  0:42 ` [PATCH 0/10] cleaning up check_repository_format_gently David Turner

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=1456867206.18017.94.camel@twopensource.com \
    --to=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    --cc=pclouds@gmail.com \
    --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.