Alfred M. Szmidt wrote: > Bob Proulx wrote: > [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.] > > git.gnu.org has "always" been an alias for git.sv.gnu.org; similar > with svn.gnu.org, cvs.gnu.org, etc. It has always worked for me, > since I cannot be bothered typing the whole thing. Not sure what > documentation you are refering too.
If it is not documented then using it is using an undocumented interface. Undocumented interfaces are not guarenteed to continue to exist. And I remember this one because it didn't exist for at least a couple of years! But then we got some reports that people complained that it should work. Not knowing where to point it to we pointed it to git.savannah.gnu.org because that was back when I was new and not as assertive about removing undocumented features. > 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 > > Is the intent to make this magic from the users side when this gets > fully implemented, so that git clone http://git.gnu.org/.. does the > right thing, and the authenticaed to the same git.gnu.org does the > right things? The reason we have the current problem is that all of the eggs are in one basket. All of the names point to one place. And that one place then cannot be redundant, cannot be scaled-out, can be scaled-up only so far, and it is failing under the onslaught of the Internet. Between the large stupid botnet and the continuous AI Crawlers it is impractical to keep all of everything on one server and expect it to work. We need to be able to distribute the services to different systems. And that requires different names. So... No. I am intending to create one name per service protocol. To allow splitting out individual services into separate systems. Because for example the current problems are almost entirely centered on the /cgit interface. If we could move it off the primary server then it would avoid all of the 502 errors people have been suffering through due to the system being overloaded. But since it uses the same hostname as all of the others it is currently stuck on the same system. All of the eggs are in one basket. Splitting that out allows this. http://cgit.git.savannah.gnu.org/cgit/coreutils.git Your web browser might automatically convert that to https, which might be problematic due to certificates, but if your browser does not then that is an example of splitting the load of it off the primary server and onto a distributed set of read-only secondaries. > Reason asking is that bots and CI/CD don't have much empathy to do the > right thing, so URLs will stay as they are ... I am trying to make the new system work before breaking the old system. But at some point people are going to have to migrate. The old URLs will need to be disabled. Right now everyone is suffering under the overloading problem. We have pushed that paradigm of having one machine doing it all for about as far as we can and it is failing under the new conditions of the hostile Internet. We are either going to need to change to adapt to the new normal or everyone will simply become too frustrated and will move away to other non-free platforms which are scaling out. > > http://git.savannah.gnu.org/r/mygroup.git > > I have no plans to propagate the /r raw mode service. > > I'm not sure what this means, or is ... You asked about the /r raw access path. That is the basic http access which git can use but git is very inefficient using it. It's slow. As far as I can determine the purpose of /r is to allow people who were trying to clone from behind corporate http proxies to be able to clone using the basic http path which should function through corporate http proxies. In the years since then there has been the big push to move from http to https and as we all know https breaks corporate http proxies since https cannot be proxied. That migration has made supporting corporate http proxies pretty much unimportant. Maybe even negatively important. Negatively because people then use it anyway and then complain (as we had a complaint recently) that /r is slow. Well yes of course it is slow, because its the dumb basic http protocol, when people should be using the smart git http backend instead. If /r were disabled then it would force people to move. It's also the same thing for people using /cgit/ for git cloning. That's terrible because it is heavy and resource intensive. But I don't know of a way to prevent it as that is all handled internally to cgit. About all that we can do is to switch to a distributed paradigm where it is scaled-out to mirror machines. > 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. > ... 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. > > Happy sailing, happy hacking and a happy speedy recovery! I am back from the sailboat! Crossed the ocean from the Bahamas to the US east coast. It was the adventure of a lifetime for certain! I am still coughing my lungs up as it seems I had the flu as diagnosed by the doctor at the clinic and it has settled in my lungs and just won't shake off. Hopefully I can get past it in the next week or two. A lot of people have been complaining of this nasty strain this year and it has been hanging on and on for a lot of them. Bob
