Page MenuHomePhorge

Expose only canonical Clone URI in Diffusion when repo hosted externally and Differential uninstalled
Closed, WontfixPublic

Description

The green "Clone" button of a Diffusion repo by default seems to offer quite some options (in our setup at least, with /config/edit/diffusion.ssh-host/ set && diffusion.allow-http-auth being true && security.require-https being false and for older repos callsigns defined) which has confused some of our user base. Example:

  • http://phorge.localhost/diffusion/1234/foo.git
  • https://phorge.localhost/diffusion/1234/foo.git
  • ssh://vcs@ssh-host.phorge.localhost/diffusion/1234/foo.git
  • http://phorge.localhost/diffusion/ABCD/foo.git
  • https://phorge.localhost/diffusion/ABCD/foo.git
  • ssh://vcs@ssh-host.phorge.localhost/diffusion/ABCD/foo.git
  • the original canonical location URI, e.g on GitHub

So some repos throw up to 7 clone URIs at the user after clicking the "Clone" button. (It's also a valid argument to state that our configuration / repo URI management hasn't been great in the past.)

Sharing my train of thought:

When Differential is uninstalled in a Phorge installation, this implies that Diffusion does not host any canonical repo locations but only repos observed from another location.
IIUC there's no way to push a commit into a repo canonically hosted in Diffusion bypassing (uninstalled) Differential?

In this case, when a user clicks the "Clone" button in a Diffusion repository, IMHO it makes sense not to encourage folks to clone the repository from Diffusion but instead clone from the canonical code repo location.
Cloning from the canonical location will allow potential developers to propose changes by pushing custom branches etc (which they cannot do when cloning from Diffusion as it's just a read-only mirror).

Potential argument against this could be sysadmins/non-developers who want "one place from where to pull it all": Diffusion.

  • If my thought makes sense, should this be behind a config setting, or be default behavior? Basically, are there use cases that repositories are observed (mirrored into Diffusion) and the Phorge user base is supposed not to know the canonical code repository and clone from Diffusion instead?
  • If my thought does not make sense, please set the task status to declined, so I might deploy this downstream instead.

Upstreaming from https://phabricator.wikimedia.org/T361997

Event Timeline

Premising that I quite understand the difference between Differential and Diffusion, I don't get why Differential should impact Diffusion here.

I think this statement is not correct:

When Differential is uninstalled in a Phorge installation, this implies that Diffusion does not host any canonical repo locations

I can have Diffusion repositories, hosted or mirrored, and this has nothing to do with Differential.

If you want to disable Repository hosting, you just have to disable that. I think, unsetting phd.user.

https://we.phorge.it/book/phorge/article/diffusion_hosting/

Example: an organization can have 100+ hosted repositories, both Subversion and git, and the highly-trusted-staff can be allowed to push directly in these hosted repositories, for example because they just rely on heavy post-commit review with Audit. And, they can rely on Differential just to share stubs. The pre-commit review with Differential has little to do with Diffusion here.

You can set "visibility" for each URI already.

Trying to decide for all installs what the "canonical" URI is might get tricky - sometimes it's a mirror, sometimes it's an observed - we don't know for sure.

Basing the decision on "is Differential installed" is strange to me - using Differential doesn't mean you want the canonical repo to be local, and an install can use only Audit for code reviews.

Adding a config option is also not something that we normally like.


Counter proposal:

  • Explicitly mark one URI as "primary", and display that more prominently in the "clone" dialog.

Thanks everyone for the feedback! Looks like my initial assumptions are already uncommon, so I'm going to decline this ticket for the time being.
The counterproposal makes more sense to me on an 'upstream' level, indeed.