Should the tasks in the Repository Migrations column of Gerrit-Migration be closed then?

Well, if a particular project wants to use Phabricator, they're more than welcome to. But some can probably be declined.

nb: I think you know my opinion on T119908 these days...

I disagree. I still think all repos should be sync'd to phabricator.

Phabricator doesn't only exist as an accessory for gerrit. Having repositories in Phabricator, for one thing, provides a mirror we control. Phabricator currently provides us with a multi-datacenter redundant repository hosting infrastructure. Soon we will be able to have deployments fetch from a git repo hosted in the same datacenter as the target server. If phabricator is a sunk cost then we can close a lot of open tasks and I might as well start looking for a new job.

Gerrit also provides multi-datacenter capability, so we've got local mirrors. I understand maybe wanting a non-Gerrit mirror we control...but the complete lack of organization of our repo setup there makes it a pain to work with...manual repo maintenance is the ultimate killer for me... I'd rather replicate to a random VM and expose them over git:// than the status quo.

(I'd also argue the majority of our users don't find them useful, considering how much Github gets used just for linking things if nothing else)

Now... I'd be fine with nuking them and recreating them in a sensible manner, dropping the non-branch/tag refs and having a bridge to handle creation/deletion automatically.

In T187149#3974534, @demon wrote:

Now... I'd be fine with nuking them and recreating them in a sensible manner, dropping the non-branch/tag refs and having a bridge to handle creation/deletion automatically.

+1. It should be fairly simple to automatically keep them in sync. I agree that the status quo is a mess (due to various hysterical reasons which you know very well) but that's no reason to just nuke the whole thing.

Personally, I like having the repos in Phab; I don't dislike Diffusion as much as some others do and the clean markup for linking/rending is nice. And them being here doesn't hurt anyone (modulo maintenance).

In T187149#3974534, @demon wrote:

Now... I'd be fine with nuking them and recreating them in a sensible manner, dropping the non-branch/tag refs and having a bridge to handle creation/deletion automatically.

This seems like the way forward. Can you re-title & edit the description to clarify the new intent here?

I personally strongly oppose it:

1. When a commit mentions a task ID, it will automatically displayed in the task's history
2. Diffusion provides a way to mention a commit in a task and the mention is tracked
3. Diffusion provides a way to search both repo and commit in main Phabricator search (together with other documents, and may be filtered by author)
4. Diffusion provides a way to search code pattern; I don't see similar tools in Gitiles (though there's probably some external tools)
5. Delete all Phabricator git repos that haven't been referenced make Diffusion an inconsistent state and may confuse users who want to search repos in Phabricator; either delete all Diffusion repos (this will break links in tasks) or keep all repos

As a part of T283980: Phacility (Maintainer of Phabricator) is winding down. Upstream support ending., I will now support disable Diffusion completely once all repos are mirrored to GitLab.

@Bugreporter That is completely unrelated to this task, Please post constructive task comments.

In T187149#7123493, @Peachey88 wrote:

@Bugreporter That is completely unrelated to this task, Please post constructive task comments.

This comment is intended as an amendment of my 2018 comment.