Re: Consist timestamps within a checkout/clone

From: Taylor Blau <me@ttaylorr.com>
Date: Oct 31, 2022, 20:36 UTC
Message-ID: <Y2Ax5XOgSOOcgo8J@nand.local>
In-Reply-To: <221031.86zgdb68p3.gmgdl@evledraar.gmail.com>

On Mon, Oct 31, 2022 at 09:21:20PM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 12 quoted lines

> I think you're almost certainly running into the parallel checkout,
> which is new in that revision range. Try tweaking checkout.workers and
> checkout.thresholdForParallelism (see "man git-config").
>
> I can't say without looking at the code/Makefile (and even then, I don't
> have time to dig here:), but if I had to bet I'd say that your
> dependencies have probably always been broken with these checked-in
> files, but they happend to work out if they were checked out in sorted
> order.
>
> And now with the parallel checkout they're not guaranteed to do that, as
> some workers will "race ahead" and finish in an unpredictable order.

Doesn't checkout.thresholdForParallelism only matter when checkout.workers != 1?

So what you wrote seems like a reasonable explanation, but only if the original reporter set checkout.workers to imply the non-sequential behavior in the first place.

That said...

  - I also don't know off-hand of a place where we've defined the order
    where Git will checkout files in the working copy. So depending on
    that behavior isn't a safe thing to do.

  - Committing build artifacts into your repository is generally
    discouraged.

So while I'd guess that setting `checkout.workers` back to "1" (if it wasn't already) will probably restore the existing behavior, counting on that behavior in the first place is wrong.

Thanks, Taylor