Better `plumbing.transport.Transport` isolation?

[ggambetti]

Currently plumbing.transport.Transport items are retrieved for remotes via plumbing.transport.client.NewClient. This uses a global client.Protocols map, which creates complications for managing protocols across application packages and goroutines.

I'm wondering if there's another way to organize the protocol handling to avoid the global state, or passing a map[string]transport.Transport to a specific Remote?

---

I have an application that clones and processes Git repositories from users. For security reasons, we only allow a subset of the default protocols: some of them need to be removed. Since it's a global map, we resort to using func init() to globally de-register disallowed protocols: as it's the only way to ensure that no go-git user ever manages to use a disallowed protocol.

As alternative motivation consider testing custom protocols: given the global client.Protocols map, multiple tests can not safely run in parallel as they risk a crash with concurrent map read and map write. And possibly failing with the race detector (go test -race ...). While this could be fixed by using sync.Map, that wouldn't address the global state.

[github-actions[bot]]

To help us keep things tidy and focus on the active tasks, we've introduced a stale bot to spot issues/PRs that haven't had any activity in a while.

This particular issue hasn't had any updates or activity in the past 90 days, so it's been labeled as 'stale'. If it remains inactive for the next 30 days, it'll be automatically closed.

We understand everyone's busy, but if this issue is still important to you, please feel free to add a comment or make an update to keep it active.

Thanks for your understanding and cooperation!