Re: [PATCH v2 11/19] parallel-checkout: make it truly parallel

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

 



Hi, Martin

On Tue, Sep 29, 2020 at 4:52 PM Martin Ågren <martin.agren@xxxxxxxxx> wrote:
>
> Hi Matheus,
>
> On Wed, 23 Sep 2020 at 00:53, Matheus Tavares <matheus.bernardino@xxxxxx> wrote:
> > --- a/Documentation/config/checkout.txt
> > +++ b/Documentation/config/checkout.txt
> > @@ -16,3 +16,24 @@ will checkout the '<something>' branch on another remote,
> >  and by linkgit:git-worktree[1] when 'git worktree add' refers to a
> >  remote branch. This setting might be used for other checkout-like
> >  commands or functionality in the future.
> > +
> > +checkout.workers::
> > +       The number of parallel workers to use when updating the working tree.
> > +       The default is one, i.e. sequential execution. If set to a value less
> > +       than one, Git will use as many workers as the number of logical cores
> > +       available. This setting and checkout.thresholdForParallelism affect all
>
> If you end up rerolling this patch series for other reasons, you might
> want to consider using `backticks` around
> `checkout.thresholdForParallelism` so that it gets typeset as monospace.

Sure, thanks!

> > +       commands that perform checkout. E.g. checkout, switch, clone, reset,
> > +       sparse-checkout, read-tree, etc.
>
> Similarly here. Or perhaps go for "linkgit:git-checkout[1],
> linkgit:git-switch[1]" etc.
>
> BTW, as far as ".e.g.," goes, this list looks quite long. :) I almost
> get the feeling you've made it fairly exhaustive and added the "e.g.,"
> more as future proofing than anything else. I don't think anyone would
> complain if you left out, say, the plumbing `git read-tree` from the list.

Yeah, I might have gotten a little too carried away there hehe :)

> > +Note: parallel checkout usually delivers better performance for repositories
> > +located on SSDs or over NFS. For repositories on spinning disks and/or machines
> > +with a small number of cores, the default sequential checkout often performs
> > +better. The size and compression level of a repository might also influence how
> > +well the parallel version performs.
> > +
> > +checkout.thresholdForParallelism::
>
> Sorry if this has already been discussed, but this "For" looks somewhat
> odd. Basically every config knob is "somethingForSomething". ;-) Could
> this be `checkout.parallelismThreshold`?

Thanks for the suggestion. TBH, I spent more time than I'd like to
admit trying to come up with a name for this setting... But
`checkout.parallelismThreshold` does sound better.




[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]

  Powered by Linux