On Wed, 19 Dec 2018 21:33:29 -0500 Rich Freeman wrote: > I'm not sure how necessary this is, but another way to do this is to > just use tags, perhaps date-based (eg year-month). Perhaps this could > be combined with some level of QA as well to ensure the tree is clean > at the time it was tagged. From the command line this would be > simpler than copy/pasting hashes from some webpage, but it obviously > clutters the repo. Granted, it isn't much clutter if you only do it > monthly. Ew. Please no. Even when used appropriately, tags create a lot of mess when dealing with repos on a regular basis. Using them to simply communicate metadata is just wrong. My suggestion would probably be easier with some instrumentation in portage if we worked out how to do it, eg: emerge --sync-to=2018-12-21 *maybe* it could be done with a ref spec that doesn't collide with the tag/head space, enough that they show up in git ls-remote, but otherwise don't involve reference copying when people do naive git clones on stock configuration ( because syncing a bunch of tags that will never be useful after you've synced them is um... ) The downside though of that is using non-standard ref names will mean mirrors won't clone them by default. > Git fetch does not seem to support any kind of relative refspec. You > need a hash/branch/tag/ref. Git ls-remote just lists refs and not > history. > If super-unreliable connections are the concern it probably would be > cleaner to just use the previous suggestion of providing bundles with > resume support. They can be downloaded and then pulled/fetched from. > Do we really have that much of a need for this? Indeed, there's also the opportunity to replicate bundles via bittorrent, but not sure how much demand there is for that either.