When I sent out my RFC series there seemed to be a lot of interest but I
haven't seen many people jump to review this series. Despite lack of review I
wanted to get out another version which includes some changes to fix things
that were bugging me about the series. Hopfully this v2 will prod some
On Thu, 8 Jun 2017 16:40:28 -0700
Brandon Williams wrote:
> When I sent out my RFC series there seemed to be a lot of interest but I
> haven't seen many people jump to review this series. Despite lack of review I
> wanted to get out another version which includes some changes to fix things
> th
On Fri, Jun 09, 2017 at 05:40:34PM -0700, Jonathan Tan wrote:
> Before I get into the details, I have some questions:
>
> 1. I am concerned that "struct repository" will end up growing without
> bounds as we store more and more repo-specific concerns in it. Could it
> be restricted to just the fi
On Sat, Jun 10, 2017 at 02:07:12AM -0400, Jeff King wrote:
> I think the repository object has to become a kitchen sink of sorts,
> because we have tons of global variables representing repo-wide config.
> ls-files doesn't respect a lot of config, but what should, e.g.:
>
> git config core.quot
On 06/10, Jeff King wrote:
> On Fri, Jun 09, 2017 at 05:40:34PM -0700, Jonathan Tan wrote:
>
> > Before I get into the details, I have some questions:
> >
> > 1. I am concerned that "struct repository" will end up growing without
> > bounds as we store more and more repo-specific concerns in it.
On 06/10, Jeff King wrote:
> On Sat, Jun 10, 2017 at 02:07:12AM -0400, Jeff King wrote:
>
> > I think the repository object has to become a kitchen sink of sorts,
> > because we have tons of global variables representing repo-wide config.
> > ls-files doesn't respect a lot of config, but what shou
On Fri, Jun 9, 2017 at 11:07 PM, Jeff King wrote:
> On Fri, Jun 09, 2017 at 05:40:34PM -0700, Jonathan Tan wrote:
>
>> Before I get into the details, I have some questions:
>>
>> 1. I am concerned that "struct repository" will end up growing without
>> bounds as we store more and more repo-specifi
On Sat, 10 Jun 2017 02:07:12 -0400
Jeff King wrote:
> I do agree that "pass just what the sub-function needs" is a good rule
> of thumb. But the reason that these are globals in the first place is
> that there are a ton of them, and they are used at the lowest levels of
> call chains. So I have a
On Sat, 10 Jun 2017 17:43:29 -0700
Brandon Williams wrote:
> I disagree with a few points of what jonathan said (mostly about
> removing the config from the repo object, as I like the idea of nothing
> knowing about a 'config_set' object) and I think this problem could be
> solved in a couple way
On 06/12, Jonathan Tan wrote:
> On Sat, 10 Jun 2017 02:07:12 -0400
> Jeff King wrote:
>
> > I do agree that "pass just what the sub-function needs" is a good rule
> > of thumb. But the reason that these are globals in the first place is
> > that there are a ton of them, and they are used at the l
On Mon, 12 Jun 2017 12:11:21 -0700
Brandon Williams wrote:
> On 06/12, Jonathan Tan wrote:
> > On Sat, 10 Jun 2017 02:07:12 -0400
> > Jeff King wrote:
> >
> > > I do agree that "pass just what the sub-function needs" is a good rule
> > > of thumb. But the reason that these are globals in the fi
On Sun, Jun 11, 2017 at 10:24:12PM -0700, Stefan Beller wrote:
> On Fri, Jun 9, 2017 at 11:07 PM, Jeff King wrote:
> > On Fri, Jun 09, 2017 at 05:40:34PM -0700, Jonathan Tan wrote:
> >
> >> Before I get into the details, I have some questions:
> >>
> >> 1. I am concerned that "struct repository"
On Mon, Jun 12, 2017 at 01:04:09PM -0700, Jonathan Tan wrote:
> > I'm not sure I know what you mean by config variables which are static,
> > are you referring to the in-memory options which are populated by
> > querying the config? Those I wouldn't want to see placed in a
> > 'repository object'
13 matches
Mail list logo
