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'
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, 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 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 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 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 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 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 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 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 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 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
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
13 matches
Mail list logo
