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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Apr 16, 2016, 05:17 UTC
Message-ID: <5711CACF.9060204@alum.mit.edu>
In-Reply-To: <20160415165208.GA17928@sigill.intra.peff.net>

On 04/15/2016 06:52 PM, Jeff King wrote:

Show 23 quoted lines

> On Fri, Apr 15, 2016 at 01:18:46PM +0200, Christian Couder wrote:
> 
>> On Fri, Apr 15, 2016 at 11:51 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>>> On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:
>>>>
>>>> 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.
> Git does not promise a particular timing or order for updating files as
> it is. So if we are checking out two files "a" and "b", and your build
> process depends on the timestamp between them, I think all bets are
> already off.

I'm hazy on this, but I think somebody at Git Merge pointed out that parallel checkouts (within a single repository) could be tricky if multiple Git filenames are mapped to the same file due to filesystem case-insensitivity or encoding normalization.

Michael