Community
Participate
Working Groups
A few years ago we've moved all our Git repositories to Gerrit. Gerrit supports anonymous cloning via https and we've kept the legacy git:// protocol around. The current git:// protocol is handled by antique servers that we are planning on terminating. Rather than move the (arguably obsolete) git:// protocol to another server, we will simply terminate it, as it does not see much usage anymore. To do this, here's what I propose: 1. Immediately, remove publicizing availability of Anonymous git:// from Gerrit. Anonymous https would remain, as it's the best way to do anonymous git. 2. Immediately, remove publicizing availability of Anonymous git:// from cGit, at https://git.eclipse.org/c/. Anonymous https links would remain. 3. Immediately, communicate our intentions to the community. 4. Schedule two or three brownouts - perhaps June 25 and July 9 and July 23, with a shut-off date of July 31.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit-pipelines/+/181739
Gerrit change https://git.eclipse.org/r/c/egit/egit-pipelines/+/181739 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit-pipelines.git/commit/?id=3ffcd526dc7245dbabd9c1cc3dae4ca23198a4c1
There are also git links for clone in many of the project pages. https://projects.eclipse.org/projects/technology.packaging/developer Review With Gerrit https://git.eclipse.org/r/q/epp%2Forg.eclipse.epp.packages Browse Repository https://git.eclipse.org/r/plugins/gitiles/epp/org.eclipse.epp.packages Clone: git://git.eclipse.org/gitroot/epp/org.eclipse.epp.packages.git
(In reply to Andrew Johnson from comment #3) Great catch. I'll see if we can mass-update all those.
Links in the PMI are being cleaned up. Links on cGit have been changed too. Matt will be sending another reminder email today, and I've scheduled the brownout dates as per comment 0.
The mirrors on github still use the git:// protocol, e.g. https://github.com/eclipse/eclipse.jdt.core says: "mirrored from git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git"
(In reply to Till Brychcy from comment #6) > The mirrors on github still use the git:// protocol, e.g. > > https://github.com/eclipse/eclipse.jdt.core I think we need to remove github mirrors. I think they are generally not used, often receive PRs that go ignored.
(In reply to Denis Roy from comment #7) > (In reply to Till Brychcy from comment #6) > > The mirrors on github still use the git:// protocol, e.g. > > > > https://github.com/eclipse/eclipse.jdt.core > > > I think we need to remove github mirrors. I think they are generally not > used, often receive PRs that go ignored. More than once I have used github to find out which of the many Eclipse repos I need to clone - then I've cloned them from git.eclipse.org. AFAICS the search on https://git.eclipse.org/c/ only allows searching by repo name, not by file names or file content.
Brownout #2 is in progress.
(In reply to Denis Roy from comment #7) > (In reply to Till Brychcy from comment #6) > > The mirrors on github still use the git:// protocol, e.g. > > > > https://github.com/eclipse/eclipse.jdt.core > > > I think we need to remove github mirrors. I think they are generally not > used, often receive PRs that go ignored. I use GitHub code search on a daily basis to find usages and browse code. It would be a shame if this would no longer be available for Eclipse projects.
(In reply to Sebastian Zarnekow from comment #10) > > I think we need to remove github mirrors. I think they are generally not > > used, often receive PRs that go ignored. > > I use GitHub code search on a daily basis to find usages and browse code. It > would be a shame if this would no longer be available for Eclipse projects. AFAIK the removal was needed due to lack of support from GitHub itself for mirrors. However, I agree with the comment. The code search capability of git.eclipse.org is very poor. A solution is needed here.
Agreed. I used the GitHub mirrors to reference parts of Eclipse code (in comments) because it's really easy to quickly search for particular content, and even easier to immediately go to a particular source file. Without it I guess we could still ensure we have a cloned copy of the repo locally, search for the file and reconstruct the path from the root of the repo web view. Some kind of service that has an indexed search over the major platform project sources would have been nice.
(In reply to Gunnar Wagenknecht from comment #11) (In reply to Sebastian Zarnekow from comment #10) (In reply to Roland Grunberg from comment #12) In my rich fantasy world, the eventual state is that Eclipse projects will end up in either our Gitlab instance or on Github. That solves not only the search issue, but integrates more modern issue tracking and community interaction features, while allowing us to lower maintenance overhead somewhat. So if there are projects you'd like to be able to search, please feel free to ask them to think about moving to Gitlab or Github. -M.
(In reply to Eclipse Webmaster from comment #13) > So if there are projects you'd like to be able to search, please feel free > to ask them to think about moving to Gitlab or Github. > > -M. So you are saying "The foundation did provide this service for all projects (to be able to be mirrored by Github). This service will be shutdown without replacement. If that service was used, the user should try to work with all project individually in order to cause work for them to achieve a comparable functionality."?
FWIW: This comment indicates that there was already a first user who found some old'ish copy if jdt.core on Github and drew conclusions from that about the state of the project. https://bugs.eclipse.org/bugs/show_bug.cgi?id=565512#c5
(In reply to Sebastian Zarnekow from comment #14) > So you are saying "The foundation did provide this service for all projects > (to be able to be mirrored by Github). This service will be shutdown without > replacement. If that service was used, the user should try to work with all > project individually in order to cause work for them to achieve a comparable > functionality."? No, although I concede you could certainly choose to interpret it that way. It's awesome that you(and others) were able to leverage this Github feature to contribute or just make your day to day faster, and for what it's worth I'm sorry that this wasn't socialized very well. (In reply to Sebastian Zarnekow from comment #15) I don't think you're suggesting that we should have kept the older and potentially out of date Github mirrors around to confuse more people, but preventing that results in the same outcome(mirrors are removed). -M.
I'm running one last brownout of the git protocol for the next 3 hours(https://eclipse.statuspage.io). Also I'm rescheduling the shutdown from July 31st(Saturday) to EOB Friday the 30th -M.
The git:// protocol service has been shutdown. Use https:// or ssh:// URLs ie: git clone https://git.eclipse.org/r/zenoh/zenoh or git clone ssh://userid@git.eclipse.org:29418/zenoh/zenoh -M.
This will cause some trouble for some projects. Good citizens in the OSGi world were adding Eclipse-SourceReferences headers [1] to bundle manifests that are pointing to the exact commit in a certain source code management system like Git. With PDE it used to be very simple to check out exactly what you were using. Here is an example from a newer org.eclipse.osgi bundle: > Bundle-SymbolicName: org.eclipse.osgi; singleton:=true > Eclipse-SourceReferences: scm:git:git://git.eclipse.org/gitroot/equino > x/rt.equinox.framework.git;path="bundles/org.eclipse.osgi";tag="I2021 > 0226-1800";commitId=d60755236727ba69734922858db966f316bf5936 Most, or probably all projects are using the git protocol because that was the way to go at that time. [1] https://wiki.eclipse.org/PDE/UI/SourceReferences
> Most, or probably all projects are using the git protocol because that was > the way to go at that time. > > > [1] https://wiki.eclipse.org/PDE/UI/SourceReferences If that document shows how to pull code from CVS pserver like I think it does, the PDE project has some stale documentation to update :)
(In reply to Denis Roy from comment #20) > > Most, or probably all projects are using the git protocol because that was > > the way to go at that time. > > > > > > [1] https://wiki.eclipse.org/PDE/UI/SourceReferences > > If that document shows how to pull code from CVS pserver like I think it > does, the PDE project has some stale documentation to update :) :-) There is a reticence to delete stuff on the Wiki - when I added the new relevant section[1] I suppose I should have deleted all the old stuff. Anyway, I have not updated the page to remove most of the dated references to CVS and recreated the screenshots. The relevant section of the document that Markus was referring to in Comment 19 was the last section "Generating Source Reference Headers with Tycho" which was up to date, but still requires the default git.eclipse.org/ URL to be updated. [1] https://wiki.eclipse.org/index.php?title=PDE/UI/SourceReferences&diff=414621&oldid=208100
FWIW - almost none of the 2021-06 release (the current release) can be imported into Eclipse because the git:// server is gone. The error message the dev will see is this or similar: git://git.eclipse.org/gitroot/platform/eclipse.platform.debug.git: Connection timed out: connect
(In reply to Jonah Graham from comment #22) > FWIW - almost none of the 2021-06 release (the current release) can be > imported into Eclipse because the git:// server is gone. Not sure what you mean? Inported from where? We've spent time examining git:// traffic and frankly, there was none.
(In reply to Denis Roy from comment #23) > (In reply to Jonah Graham from comment #22) > > FWIW - almost none of the 2021-06 release (the current release) can be > > imported into Eclipse because the git:// server is gone. > > Not sure what you mean? Inported from where? Using the steps as documented in https://wiki.eclipse.org/PDE/UI/SourceReferences#Importing_Projects_from_Git - similar content is in eclipse help: https://help.eclipse.org/2021-06/topic/org.eclipse.pde.doc.user/guide/tools/import_wizards/import_plugins.htm and the Importing line of https://help.eclipse.org/2021-06/topic/org.eclipse.pde.doc.user/guide/tools/views/plugins.htm refers to it too. > We've spent time examining git:// traffic and frankly, there was none. I assume nearly none, rather than literally 0? I do the above operation a handful of times per year and others [1] report the same. The effect of the shutdown of the git:// protocol is basically it breaks these old links. There is precedence for this breaking change - at some point when repos were moved from CVS to Git importing older CVS releases would have failed. I wasn't really active during that transition, so I can't comment much more. I defer to others for how important this is - I just want to update the documentation that I am aware of and make sure all the right people are talking to each other. [1] https://www.eclipse.org/lists/jdt-dev/msg01884.html
Are there also any plans to disable access over unencrypted HTTP (http://)? For example by responding with HTTP 501. At the moment the Git server does seem to upgrade these requests to HTTPS, but an attacker could probably perform a man-in-the-middle attack preventing this upgrade to HTTPS and serving malicious repository content. A request from Git can be identified by its "Git-Protocol" HTTP header, see https://git-scm.com/docs/protocol-v2. Regarding GitHub mirrors: https://github.com/eclipse-mirrors has unofficial mirrors for some of the Eclipse projects. Maybe you could utilize similar GitHub Actions as defined in https://github.com/eclipse-mirrors/eclipse-mirrors to have GitHub update the mirrors. > I think they are generally not used, often receive PRs that go ignored. GitHub Actions could also help with this by automatically commenting on the pull requests, letting users know that this is only a mirror, and closing the pull request.
I would suggest filing a separate issue. Thanks.
It still feels really detrimental to have deleted all mirrors. Many contributors have already complained about the resulting loss of features such as search, and the cost of that removal is unfortunately increasing over time as GitHub improves its feature set but git.eclipse.org stays behind. In addition to this, another advantage of mirrors is that contributions were automatically linked in the GitHub contribution graph, the activity overview, optional pinned respositories, etc. Many unpaid open-source contributors do care about building a portfolio and showcasing their work publicly, and removing the mirrors went against this. Am I really encouraged to contribute to a project if my contributions aren't surfaced anywhere and stay hidden in an obscure system? If "the eventual state is that Eclipse projects will end up in either our Gitlab instance or on Github", then that should have been the main focus, and any useful integrations should have been kept around until the transition was complete.
