Re: Parallel checkout (Was Re: 0 bot for Git)

Jeff King [off-list ref] writes:

On Fri, Apr 15, 2016 at 01:18:46PM +0200, Christian Couder wrote:

quoted

On Fri, Apr 15, 2016 at 11:51 AM, Duy Nguyen [off-list ref] wrote:

quoted

On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:

quoted

There is a draft of an article about the first part of the Contributor
Summit in the draft of the next Git Rev News edition:

https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-14.md

Thanks. I read the sentence "This made people mention potential
problems with parallelizing git checkout" and wondered what these
problems were.

It may have been Michael or Peff (CC'ed) saying that it could break
some builds as the timestamps on the files might not always be ordered
in the same way.

I don't think it was me. I'm also not sure how it would break a build.

Yup, "will break a build" is a crazy-talk that I'd be surprised if
you said something silly like that ;-)

Last time I checked, I think the accesses to attributes from the
convert.c thing was one of the things that are cumbersome to make
safe in multi-threaded world.

On Fri, Apr 15, 2016 at 10:31:39AM -0700, Junio C Hamano wrote:

Last time I checked, I think the accesses to attributes from the
convert.c thing was one of the things that are cumbersome to make
safe in multi-threaded world.

Multi-threaded grep has the same problem. I think we started with a big
lock on the attribute access. That works OK, as long as you hold the
lock only for the lookup and not the actual filtering. We later moved to
pre-loading the attributes in 9dd5245c104, because looking up attributes
in order is much more efficient (because locality of paths lets us reuse
work from the previous request).

So I'm guessing the major work here will be to split the "look up smudge
attributes" step from "do the smudge".

-Peff