Hi Chris,
Thank you for this follow-up information.
I think that for the use cases we are aware of for the near term, the changes you have proposed around the introduction of a new HttpConnectionFactory (15123 and 15124) would provide the basic extensibility that we need. We know that we'll have different applications running within the same JVM process that need to use SSL and may require different certificate management configurations.
We don't know yet how many of these applications might need to use jgit, though, and, for any cases where more than one might be present, whether they would always be operating on separate repos and/or would need to use different certificate management configurations.
The ability to configure the SSL parameters differently per the repository configuration (3199 and 3200) is definitely intriguing. I could see where this could offer us more flexibility.
I think the ideal functionality for us would be to have the ability for the direct client performing the operations against the repository (e.g., a fetch or push) to be the one which sets the SSL configuration parameters it would like to have used and not have those parameters affect any other client. In conjunction with your changes for (3199 and 3200), I could see where something close to this could be achieved with the approach of having the client configuring the parameters through the FileBasedConfig object obtained from the Repository, although I'm not sure if the changes made to that in memory copy of the FileBasedConfig might be written back to disk and unintentionally picked up by another client using the same repository.
In any event, I think both of the sets of changes you are proposing would be very valuable and am open to any additional feedback you may have for us on our use cases.
Thanks again!
--- Jeremy