Uh? 🤔

Just to clarify, here the proposal is to close this kind of repositories (?)

https://phabricator.wikimedia.org/source/mediawiki/

Please at least evaluate all the features we are going to shutdown, with the above idea:

• We cannot mention git commits like 0f2d0d7bbb9a anymore generating an handy link
• We cannot anymore visit the https://phabricator.wikimedia.org/source/mediawiki/browse/master/ with the "pattern search" (not available to Gerrit, not available to GitLab) that use the native git grep stuff and it's super-fast.
• We cannot anymore quickly blame things and surf the permalink back in time clicking on the "<<" arrows like you can do in https://phabricator.wikimedia.org/source/mediawiki/browse/master/opensearch_desc.php
• I cannot anymore click on Open File to open that file in my editor (since I know how to configure that in my Phabricator settings) from the above URL
• I cannot anymore see people contributions in Phabricator itself, from profile pages
• ...
• ...

I have disagreed each time this general idea has been promoted in the past and I will continue to disagree until there is a material difference in the arguments made by either side.

In T317272#8222320, @bd808 wrote:

[15:56]  <    bd808> brennen, thcipriani: I am now wondering if Striker should setup a Diffusion mirror for each gitlab repo it creates. This happened as a side effect for the repos I just migrated so there will be a feature gap growing for each new repo going forward. Github gives a much better (IMO) code browser than gitiles, but It can be really nice to be able to link to a git hash in Phabricator. Thoughts?
[15:56]  <    bd808> Deciding on this would change my work for T317272
[15:56]  < stashbot> T317272: Remove legacy Diffusion related code from Striker - https://phabricator.wikimedia.org/T317272
[16:14]  <thcipriani> this was always mukundas argument for why differential should mirror everything. It is a really nice feature. I think having a mirror would make sense.
[16:29]  <  brennen> thcipriani, bd808: concur with tyler.
[16:31]  <    bd808> cool. that gives me a direction at least. It also makes me feel that I may have purged some data prematurely... but I can recreate it I think.

In T324151#8914724, @Jdforrester-WMF wrote:

Do we want to sync code into Diffusion? It's a massive point of confusion for no added value. I'd rather this task was "Ensure GitLab repos are not mirrored in Diffusion".

In T324151#8914791, @bd808 wrote:

It's a massive point of confusion for no added value.

I find it useful for the ability to embed nice links like R3254:03cff13258db: dal: Refactor and update SQL queries into tasks. The syntax needed for that is {git-hash-here} when the repo is mirrored by Diffusion. When not mirrored one can still provide explict links like https://gitlab.wikimedia.org/toolforge-repos/ifttt/-/commit/03cff13258dbb76740e19d49a4c7d25e7e75cdb8, but there is more work required to turn that into a more informative link for the casual reader like dal: Refactor and update SQL queries. As part of T296893: Replace Diffusion integration with Gitlab integration in Striker (toolsadmin) I explicitly added T317345: Mirror Striker managed GitLab repos in Diffusion for this reason.

In T324151#8916916, @thcipriani wrote:

Would love to preserve nice embedded links.

If we can link those to the canonical host, that'd be cool. Otherwise, having diffusion monitor the canonical hosts (as now) in an option (or have canonical hosts mirror, whichever).

In T358940#9608625, @Jdforrester-WMF wrote:

We could also just stop mirroring and empty the Diffusion repos whose only benefit is the auto-linking.

I prefer the ability to explicitly link commits using the {hash} and {diffusion repo:hash} methods over autoliniking which for diffusion commits and other things can be annoying. Auto linked references are not however the only use-case for Diffusion today.

Diffusion is providing a helper service for mirroring repositories to other codeforges. The open-core GitLab "Community Edition" product does not support pull mirroring, but Diffusion does. This means Diffusion can be used to pull from Gerrit or another origin and then push into GitLab. GitLab CE's push mirroring is also deficient in that it requires each origin repo to individually configure credentials for the downstream. These credentials cannot be hidden from the GitLab repo owner, nor can they be shared across repos. This makes GitLab CE's push mirroring support insufficient to implement bulk mirroring from our GitLab to other codeforges such as GutHub.

In my personal opinion, Diffusion provides a much nicer code and commit history browsing experience over Gitiles (the code browser currently used with the Wikimedia Gerrit deployment). You can compare and decide for yourself if you concur, but if we rip out Diffusion then there will not be a choice.

• https://gerrit.wikimedia.org/g/labs/striker/+/95986d360ac00d3682d47290d1488098d5cec74e
• rLSTR95986d360ac0: feat: Create Diffusion mirrors for new GitLab repos

Thanks for reporting. I have carefully examined every single point highlighted, and I think the situation is under control.

Hoping to do a good thing, I put my details directly in the original description.

Please feel free to increase the details and reopen it 🌈 And thank you for any upstream bug reports.

While I agree with @Aklapper that this task is not “invalid,” I also think that dropping Diffusion mirrors would be a big loss, and in the end users would spend more working it around than what administrators would win:

• The handy links in tasks wouldn’t work anymore (including already-inserted ones!), let that be a commit link (bb1d0aca814d), or a link to a certain file (rMW includes/recentchanges/ChangesFeed.php) or a certain line of a file (rMW includes/recentchanges/ChangesFeed.php:37 (at bb1d0aca814d)). This means having to resort to less useful links in future comments/descriptions, for which readers need more time to figure out what they mean; and even more time trying to figure out what the broken links to Diffusion (which probably won’t even be rendered as links) mean.
• The powerful repository browser. While basic code viewing functionality is present in both Gitiles and on GitHub, Gitiles cannot search for files or code at all, and GitHub doesn’t allow searching for code without logging in, which means having to have a GitHub account and potentially also means going through 2FA (searching for files is allowed on GitHub without logging in). Code navigation by clicking on an identifier is a useful feature of GitHub, but again only for logged-in users – for logged-out users, it works only within a file, which is hardly better than Ctrl+F, especially in languages as dynamic as PHP and JavaScript. (And remember: I’m not arguing for removing the GitHub mirror – the discoverability of GitHub for newbies is unbeatable –, only against removing the Diffusion one.)
• The diff views that are integrated with the rest of Phabricator:
  • Neither Gitiles nor GitHub render Phabricator task numbers as links (the Gerrit code review interface does, but Gitiles doesn’t; the workaround is clicking on the Change-Id – which is rendered as a link in Gitiles, though not on GitHub –, and clicking once again to get to Phabricator; or copying and pasting the task ID), while Diffusion of course renders them.
  • Similarly, the authorship information is more integrated into Wikimedia: if the author/comitter email address is connected to a Phabricator account, it links to that account, from which one can not only find Phabricator comments of that person, but also their Wikimedia (CentralAuth/mediawiki.org) account, so it’s possible to write to the talk page of the author instead of opening a task on Phabricator if that’s more appropriate; in contrast, Gitiles shows whatever one entered in user.name (which may be a fully different name, e.g. a made-up user name used on Wikimedia but full name used in Git) and generates no links, while GitHub links to the GitHub profile if there’s any, and nowhere if there isn’t (Diffusion also links nowhere if there’s no Phabricator account, but that’s less likely).