W dniu sob, 28.04.2018 o godzinie 16∶23 +0200, użytkownik Duy Nguyen napisał: > On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny <mgorny@xxxxxxxxxx> wrote: > > 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) We can't really rename it without breaking compatibility with all package managers out there. Preparing to do such a major change for the sake of abusing implementation detail of git doesn't look like a worthwhile idea. > > 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. -- Best regards, Michał Górny
