Re: [PATCH v2 00/32] repository object

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 should, e.g.:
> > 
> >   git config core.quotepath true
> >   git -C submodule config core.quotepath false
> >   git ls-files --recurse-submodules
> >
> > [...]
> >
> > [1] I wanted to see how Brandon's series behaved for this quotepath
> >     case, but unfortunately I couldn't get it to work in even a simple
> >     case.  :(
> > 
> >       $ git ls-files --recurse-submodules
> >       fatal: index file corrupt
> 
> Ah, this was just hitting the bug mentioned later in the thread. With
> that fix, I can see that it does indeed behave differently than the
> current code:
> 
>   git config core.quotepath true
>   git -C submodule config core.quotepath false
>   (cd submodule &&
>    echo hello >buenos_días &&
>    git add .
>   )
>   git ls-files --recurse-submodules
> 
> shows:
> 
>   submodule/buenos_días
> 
> before the patch series, and:
> 
>   "submodule/buenos_d\303\255as"
> 
> after.
> 
> Like I said, I doubt this is a bug that anybody cares much about, but
> it's hard to know what other repo-specific global-variable usage is
> lurking in low-level code.

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 ways.

I don't think that the in-memory global variable 'quotepath' (or
whatever its called) should live in the repository object (I mean it's
already contained in the config) but rather 'quotepath' is specific to
how ls-files handles its output.  So really what should happen is you
pass a pair of objects to the ls-files machinery (or any other command's
machinery) (1) the repository object being operated on and (2) an
options struct which can be configured based on the repository.  So when
recursing you can do something like the following:

  repo_init(submodule, path_to_submodule);
  configure_opts(sub_opts, submodule, super_opts)
  ls_files(submodule, sub_opts);

This eliminates bloating 'struct repository' and would allow you to have
things configured differently in submodules (which is crazy if you ask
me, but people do crazy things).

-- 
Brandon Williams



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]