Re: [PATCH v2 11/19] parallel-checkout: make it truly parallel
- From
Matheus Tavares Bernardino <matheus.bernardino@usp.br>
- Date
- Sep 30, 2020, 14:02 UTC
- Message-ID
- <CAHd-oW7ErMKqeeoF40Mq418SusbVhkL2R7W73=4mbXUiamY1mA@mail.gmail.com>
- In-Reply-To
- <CAN0heSoJvkZ+gvQwZMPW5Q0HqB0mOUnVqXiOqnPk48cDxMzAqw@mail.gmail.com>
Hi, Martin
On Tue, Sep 29, 2020 at 4:52 PM Martin Ågren <martin.agren@gmail.com> wrote:
Show 20 quoted lines
> > Hi Matheus, > > On Wed, 23 Sep 2020 at 00:53, Matheus Tavares <matheus.bernardino@usp.br> 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!
Show 10 quoted lines
> > + 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 :)
Show 11 quoted lines
> > +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.