BF: introduce GitTransportRI - a basic implementation only #4529
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this should be sufficient to address #4489
to avoid treating such RIs as ssh addresses. Current implementation of
GitTransportRI simply splits apart transport and underlying RI attributes.
Since directed toward maint I have refrained from doing any code refactoring, such as
in RI().init and in the tests check() to avoid using "ri" (and other) arguments
which might collide with fields provided in **kwargs. May be in some next sweep
those all could become prefixed (or suffixed) with _ to avoid such collisions.
We could also make this GitTransportRI immediately turn underlying RI into an
instance (ATM it is just a string), and also expose .path as all other RIs
apparently do. But again, for the sake of the quick fix for now to not cause
hard to decypher errors, I decided to postpone that.
Note: I have not attempted to actually use it in some sample case fully since
e.g. our create-sibling-github has no clue about transport::, would need to
override url it provides for the remote and may be more...
Closes #4489