Simplify/rethink branch->mirror relationship

[ahpook]

Is your feature request related to a problem?

We've gotten feedback that the relationship between mirrors and branches is both confusing and counter to user expectations. We may need to adapt the current implementation to make this easier to understand and work with.

Describe the solution you'd like

The current state can be described as:

A public fork has N [ fork's topic branch -> main on private mirror ] relationships that ICF manages. The private mirrors may have work in flight in their own branches but when that work is merged to main, the sync to their topic branch on the public fork ( middle column in the diagram ) happens - and that topic branch becomes the basis for a PR upstream.

But this results in a proliferation of mirrors and a mix of branches on the fork that might map to upstream, might map to work directly on the fork, or might be part of a ICF-managed mirror. Additionally, at least one user says they expected a mapping of [ fork topic branch -> mirror topic branch ] and was surprised at the current implementation.

So this at least requires better explanation if not some additional work to simplify this mapping.

Describe alternatives you've considered

No response

Additional context

No response

[ahpook]

This has come up a lot for people who want to maintain long-running private mirrors that are effectively their internal fork of an upstream project. One typical use-case is that there's an upstream project which has some additional "secret sauce" added locally - code which will never be contributed upstream - but the internal team that owns the fork needs a way to continue to update their fork to keep current with upstream and continually rebase their local modifications. Currently this is a painful process; PMA doesn't directly address it because we expect that private mirror branches are ephemeral and will be closed out as soon as the contribution is merged upstream.

[riley-kohler]

Given the interest here, I wanted to share out a potential alternative branch-based contribution model that I drew up. It makes use of "magic words" in this example being "sync_" but would greatly help with user experience of the contribution process through private-mirrors.

[wrslatz]

I don't mind sync_ as a magic branch prefix necessarily. It's more clear and shorter than contrib_ which was something I was thinking about.

[wrslatz]

Would a user create a branch on the public fork and then instruct Private Mirrors to sync that through the UI? So branch name would be an additional input in the process, maybe with a default to the default branch?

[riley-kohler]

In my mind branch name would be the only input to the process (through the UI) and private-mirrors would create all of the necessary branches for you.

[wrslatz]

In my mind branch name would be the only input to the process (through the UI) and private-mirrors would create all of the necessary branches for you.

If this could support the branch already existing on the public fork, that would be best. This would help in cases where someone wants to sync and work on changes from upstream that aren't in the default branch.