Alfred M. Szmidt wrote: > Would it make sense to somehow split git clone from "logged in user" > when doing git clone, and have two servers ... the idea would be to > reduce load on git.gnu.org.
That is an excellent idea. And as it turns out we have been working on just such a thing. I have been hesitant to mention it because things are still in that experimental stage and perhaps not fully stable. But things seem to be making progress so I guess I will mention it and let you try it out. [Aside: Where is git.gnu.org documented? I recall this being reported as not working a few years ago and we just made it point to git.savannah.gnu.org because we didn't know what else it would point to but also not having seen it documented anywhere. I have always assumed this was something list in the sands of time.] > That is, > > If you clone from these two: > > git://git.savannah.gnu.org/mygroup.git This is the anonymous git:// protocol. > ssh://git.savannah.gnu.org/srv/git/mygroup.git This will always be authenticated ssh. So far we have had less trouble with ssh specifically because it is authenticated. > https://git.savannah.gnu.org/git/mygroup.git > http://git.savannah.gnu.org/git/mygroup.git > http://git.savannah.gnu.org/r/mygroup.git > > If you clone from these, you clone from a read-only clone copy (that > will have delayed updated). > > Not sure how hard that would be to implement, but maybe it would > reduce the AI bots, BlubHub, etc pulling infinite mirrors, and make it > more stable for those working on GNU software? We have implemented the un-certificated service protocols on a single non-Boston datacenter node currently with the goal of setting up multiple distributed Round Robin DNS nodes contributed by volunteers. RR-DNS works well for un-certificated service protocols. Does not work well for certificated service protocols. For git fetch operations from the read-only node feel free to try these un-certificated protocol URLs. I think the naming for these is fairly stable. I will list them as examples using grep because the paths are somewhat different for each of them and I think having a working example is useful. git clone git://git.git.savannah.gnu.org/grep.git git clone http://http.git.savannah.gnu.org/git/grep.git Those two should cover 99.44% (obviously I just swag'd that number from a bar of soap) of the CI/CD use cases. The mirrored repository part of the mirror should start an rsync with the upstream git repo 2 minutes after upstream changes stop changing. Because people tend to cluster changes (git push, git commit, git push, repeat) and it only makes sense to wait until they pause. Additionally there is a full rsync update hourly in case the event driven notifications are lost. Lost due to network outage or whatever. I am sure everyone will ask about using https for the git-http-backend smart http protocol. That would be a certificated service and it will have all of the same problems. Something has been set up but it is LIKELY TO CHANGE NAMING. I know if I don't mention it that everyone will nag to ask about it. I know that if I do mention it that people will use it and then complain when it must change. You have been warned. git clone https://https.git.savannah.gnu.org/git/grep.git (UNSTABLE NAMING) It's the https certificates which will likely cause this to change. Because RR-DNS is incompatible with certificates in the simple case. But maybe we can make it work. Stand by while we continue to develop it. Additionally and very likely to change URL names there are cgit and git set up now, implementing https. https://cgit.git.savannah.gnu.org//cgit/ https://gitweb.git.savannah.gnu.org//gitweb/ Those names and paths might need to change but for the moment maybe having them even temporarily will give some relief? I would avoid using them in documentation which will persist because again they are likely not stable naming yet. You have been warned. > http://git.savannah.gnu.org/r/mygroup.git I have no plans to propagate the /r raw mode service. As far as I can tell it was implemented to give people behind restrictive corporate networks forced to use an http proxy a way to clone through those. I can't see any other use for it. That was some years ago before the encrypt-everything movement which obviated those corporate http proxies. And personally I have always experienced problems with http proxies anyway. It's an additional reason to use https to force avoiding those data mangling proxies mostly broken. I have been contemplating removing the /r raw service as it is the slowest and most inefficient form of git fetch protocol. Use the /git smart git-http-backend service instead. It's the fast and efficient protocol. In the above I have used the long canonical form *.savannah.gnu.org for names but the *.sv.gnu.org and *.sv.nongnu.org names are also available too. A personal note from me. I am currently on travel. I am actually sitting on the deck of a sailboat typing this at the moment. I am offline much of the day and some days completely. It depends upon where we are going with the boat and what needs to be happening while on it. I am working through recent tragic events and for those who know this is a very good activity for me. I will be on the net as I can be and will be working on specific targeted things as I can work on them. And at the moment I have caught some germ from the airline, or from before, or something and am rather sick with a respiratory ailment of some type. I feel okay mostly. But if you heard my voice right now you would definitely believe that I am sick! I am being sent to the clinic here in a few minutes because of it. Bob
