From: Brandon Williams <bmwill@google.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, gitster@pobox.com, jrnieder@gmail.com
Subject: Re: [PATCH 0/4] config.h
Date: Mon, 12 Jun 2017 15:06:05 -0700 [thread overview]
Message-ID: <20170612220605.GF154599@google.com> (raw)
In-Reply-To: <20170612220244.dcndhmxpnsz2tg5d@sigill.intra.peff.net>
On 06/12, Jeff King wrote:
> On Mon, Jun 12, 2017 at 02:53:52PM -0700, Brandon Williams wrote:
>
> > > These all seem reasonable to me. Patch 3 made me shrug a little, because
> > > it seems like the majority of C files end up including it anyway. I
> > > suspect you could break config.h down into two files: the few things
> > > that everybody needs (git_config() and the few parsing functions needed
> > > in callbacks) and the ones for commands that actually manipulate the
> > > config.
> > >
> > > That would reduce the surface area of the module that most callers look
> > > at, but I don't think there's a huge benefit to doing so (mostly it just
> > > makes re-compiling faster by decreasing the chance that a dependent
> > > header has changed for each file).
> >
> > Yes, ultimately I think it would be a good thing to break config.c down
> > into at least 2 more files (the file parsing logic and the config_set
> > logic) but that can be done at a later point. I started looking at
> > doing that now but that logic is a little more entangled than I thought
> > it was.
>
> To be clear, I don't mind that sort of module refactoring and like the
> results. But it almost certainly isn't the biggest bang-for-buck in
> terms of the time it takes versus the benefit it brings. So take my
> comment as "we could also do..." but not "we should not take your patch
> because it does not go far enough".
Yes, that's how I understood your comment. I realize that there's a lot
of improvements that can be done across our code base and one rabbit
hole that is easy to fall into is "fix all the things right now!" hence
why I decided to defer doing that to a later date. And I agree that
doing that extra work doesn't buy us 'all too much'.
Having said that I do think it was worthwhile to remove the config
declarations from cache.h. I think in the long term it would be nice to
limit cache.h's scope as it is very unapproachable in its current form.
--
Brandon Williams
next prev parent reply other threads:[~2017-06-12 22:06 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 21:34 [PATCH 0/4] config.h Brandon Williams
2017-06-12 21:34 ` [PATCH 1/4] config: create config.h Brandon Williams
2017-06-12 21:34 ` [PATCH 2/4] config: remove git_config_iter Brandon Williams
2017-06-13 0:49 ` Jonathan Nieder
2017-06-13 0:57 ` Jeff King
2017-06-12 21:34 ` [PATCH 3/4] config: don't include config.h by default Brandon Williams
2017-06-12 21:34 ` [PATCH 4/4] config: don't implicitly use gitdir Brandon Williams
2017-06-13 1:05 ` Jonathan Nieder
2017-06-13 1:23 ` Brandon Williams
2017-06-13 1:33 ` Jonathan Nieder
2017-06-13 1:38 ` Jonathan Nieder
2017-06-13 2:59 ` Jeff King
2017-06-13 6:16 ` Brandon Williams
2017-06-13 6:45 ` Jeff King
2017-06-13 7:08 ` Jeff King
2017-06-13 14:43 ` Brandon Williams
2017-06-13 17:06 ` Jonathan Nieder
2017-06-13 5:52 ` Brandon Williams
2017-06-13 6:29 ` Jeff King
2017-06-13 14:47 ` Brandon Williams
2017-06-12 21:45 ` [PATCH 0/4] config.h Jeff King
2017-06-12 21:53 ` Brandon Williams
2017-06-12 22:02 ` Jeff King
2017-06-12 22:06 ` Brandon Williams [this message]
2017-06-13 1:07 ` Jonathan Nieder
2017-06-13 21:03 ` [PATCH v2 0/6] config.h Brandon Williams
2017-06-13 21:03 ` [PATCH v2 1/6] config: create config.h Brandon Williams
2017-06-13 21:13 ` Jonathan Nieder
2017-06-13 21:03 ` [PATCH v2 2/6] config: remove git_config_iter Brandon Williams
2017-06-13 21:14 ` Jonathan Nieder
2017-06-13 21:03 ` [PATCH v2 3/6] config: don't include config.h by default Brandon Williams
2017-06-13 21:58 ` Jonathan Nieder
2017-06-13 21:03 ` [PATCH v2 4/6] config: don't implicitly use gitdir Brandon Williams
2017-06-13 21:08 ` Jonathan Nieder
2017-06-13 21:38 ` Brandon Williams
2017-06-13 21:51 ` Jonathan Nieder
2017-06-13 21:55 ` Junio C Hamano
2017-06-13 22:05 ` Jonathan Nieder
2017-06-14 4:40 ` Jacob Keller
2017-06-14 6:25 ` Jeff King
2017-06-14 17:14 ` Brandon Williams
2017-06-13 21:03 ` [PATCH v2 5/6] setup: teach discover_git_directory to respect the commondir Brandon Williams
2017-06-14 6:15 ` Jeff King
2017-06-14 17:19 ` Brandon Williams
2017-06-13 21:03 ` [PATCH v2 6/6] config: respect commondir Brandon Williams
2017-06-14 18:07 ` [PATCH v3 0/6] config.h Brandon Williams
2017-06-14 18:07 ` [PATCH v3 1/6] config: create config.h Brandon Williams
2017-06-14 18:07 ` [PATCH v3 2/6] config: remove git_config_iter Brandon Williams
2017-06-14 18:07 ` [PATCH v3 3/6] config: don't include config.h by default Brandon Williams
2017-06-14 18:07 ` [PATCH v3 4/6] setup: teach discover_git_directory to respect the commondir Brandon Williams
2017-06-14 18:07 ` [PATCH v3 5/6] config: respect commondir Brandon Williams
2017-06-14 18:07 ` [PATCH v3 6/6] config: don't implicitly use gitdir or commondir Brandon Williams
2017-06-15 19:59 ` [PATCH v3 0/6] config.h Junio C Hamano
2017-06-15 20:33 ` Brandon Williams
2017-06-15 21:09 ` Junio C Hamano
2017-06-15 21:18 ` Brandon Williams
2017-06-16 0:12 ` Brandon Williams
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=20170612220605.GF154599@google.com \
--to=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@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.