Re: [RFC PATCH] checkout: Force matching mtime between files

From: Duy Nguyen <pclouds@gmail.com>
Date: Apr 28, 2018, 14:23 UTC
Message-ID: <CACsJy8AfE4XMgTLuM=9aWV7eX5Hd8CqmFMuEgQaSxsLfGoBb5w@mail.gmail.com>
In-Reply-To: <1524753972.1088.9.camel@gentoo.org>

On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny <mgorny@gentoo.org> wrote:

Show 12 quoted lines

> For the record, we're using this with ebuilds and respective cache files
> (which are expensive to generate).  We are using separate repository
> which combines sources and cache files to keep the development
> repository clean.  I have researched different solutions for this but
> git turned out the best option for incremental updates for us.
>
> Tarballs are out of question, unless you expect users to fetch >100 MiB
> every time, and they are also expensive to update.  Deltas of tarballs
> are just slow and require storing a lot of extra data.  Rsync is not
> very efficient at frequent updates, and has significant overhead
> on every run.  With all its disadvantages, git is still something that
> lets our users fetch updates frequently with minimal network overhead.

I assume you're talking about the metadata directory in gentoo-x86 repo. This specific case could be solved by renaming metadata to _metadata or something to put it on the top. "git checkout" always updates files in strcmp(path) order. This guarantees time(_metadata) <= time(ebuild) for all ebuilds without any extra touching (either in git or in a post-checkout hook)

The behavior has been this way since forever and as far as I can tell very unlikely to change at least for branch switching (major changes involved around the index). It's a bit easier to accidentally change how "git checkout -- path" works though. I don't know if we could just make this checkout order a promise and guarantee not to break it though. For it it does not sound like it adds extra maintenance burden.

-- 
Duy