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