Patch Set 2: I would prefer that you didn't submit this

I think this is the wrong thing to do. We want this information to be stored in JGit, not in EGit. The goal was to provide a transparent mechanism by which the existence of a protocol could be refactored into a method which could then later be delegated to JGit, not by implementing the full set of representation/lookups in EGit.

Secondly, an enum is almost always the wrong choice when trying to build a system which is extensible after the fact. Whether or not adding a new item is backwardly binary compatible is missing the point - if you bake in the full (and closed) set into source code, then it is impossible to externally add a new provider afterwards without modifying that source code. As an example, CDT shipped with an enum of languages (C, CPP) which made it impossible to write an Objective C addition without source code changes - and that then required an entire yearly release cycle for CDT's base to have that new enum constant in. Although the release cycles for EGit are shorter, the same problem exists - bake it into a fixed set now, and it can't be updated externally. That means that post 0.9 (say) even if someone does develop a new protocol which is entirely workable - even if it gets baked into master - no-one who has 0.9 checked out can take advantage of that, even if it's completely compatible with 0.9 unless a 0.9.1 (or 0.9.2) is released with a new constant/entry in the enum class.

Enums don't mix with dynamic extensibility. It would be even worse if this became a public class in JGit. (A class would be better than an enum since this can then be externally instantiated by new providers after the fact.)