Re: What's cooking in git.git (Aug 2020, #07; Thu, 27)

[Matheus Tavares Bernardino <matheus.bernardino@usp.br>]

Hi, Elijah

On Thu, Aug 27, 2020 at 11:16 PM Elijah Newren <newren@gmail.com> wrote:
>
> On Thu, Aug 27, 2020 at 2:46 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > * mt/grep-sparse-checkout (2020-06-12) 6 commits
> >  - config: add setting to ignore sparsity patterns in some cmds
> >  - grep: honor sparse checkout patterns
> >  - config: correctly read worktree configs in submodules
> >  - t/helper/test-config: facilitate addition of new cli options
> >  - t/helper/test-config: return exit codes consistently
> >  - doc: grep: unify info on configuration variables
> >
> >  "git grep" has been tweaked to be limited to the sparse checkout
> >  paths.
> >
> >  Review needed on 4/6; otherwise looking sane.
> >  cf. <CABPp-BGdEyEeajYZj_rdxp=MyEQdszuyjVTax=hhYj3fOtRQUQ@mail.gmail.com>
>
> Kinda disappointed to see this stalled out; especially after so much
> work put into it.  This spawned lots of other side discussions and a
> topic or two outside this series as well.  I really like the overall
> result we came up with out of this series and would like to see it
> land [...]

Yeah, I would also really like to see it land :) Thanks to your last
rounds of review, I think we got to a much better design regarding
each grep case.

>  [...] If we can't get more reviewers, maybe we just merge it down
> anyway?  But, in an attempt to prod some review...
>
> Jonathan: I pinged you in chat about this series some time ago and you
> said you'd take a look and comment.  I can't find a reference
> anywhere, but maybe you talked with Matheus in IRC somewhere?  Do you
> recall?
>
> Matheus: Do you have any outstanding items for this series or is it
> good as far as you know?

Hm, I don't have anything else planned to add.

Just one minor aesthetic consideration: should we perhaps eliminate
the sparse-checkout.c file (and the accompanying header) from the last
patch? This file contains only one function; It was created with the
idea of being later populated by another parallel series [1]. However,
if we only have this function for now, should we move it elsewhere?
I'm not sure where, though. Maybe to config.c, together with
git_config_get_index_threads() and others?

[1]: https://lore.kernel.org/git/2188577cd848d7cee77f06f1ad2b181864e5e36d.1588857462.git.gitgitgadget@gmail.com/