feat(settings): custom shortcuts
It makes the prefixes (currently gh: and gl:) customizable using user settings, allowing to:
- add your own (remote and local)
- override the existing ones (especially to force ssh access on private repositories)
- benefit from specific GitHub and GitLab behavior on alternative, private or corporate instances
It moves URL normalization into the settings to benefit from custom shortcuts.
Some decisions are required on the vcs.get_repo() behavior:
it currently only assumes https://gitlab and https://github are http git repositories, unless prefixed with git+.
However, non git remotes are not supported, so I wonder if it would be simpler to consider all https:// as git repositories (it would fail if this is not the case, whatever this method returns)
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 97.93%. Comparing base (
1dabe8e) to head (2881060).
Additional details and impacted files
@@ Coverage Diff @@
## master #1941 +/- ##
==========================================
- Coverage 97.93% 97.93% -0.01%
==========================================
Files 53 53
Lines 5677 5705 +28
==========================================
+ Hits 5560 5587 +27
- Misses 117 118 +1
| Flag | Coverage Δ | |
|---|---|---|
| unittests | 97.93% <100.00%> (-0.01%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
So, back to this one ! As written in the PR description 👆🏼, given this discussion, I'd like to know the direction I should give to this PR:
- should it assume that all http URLs are git repositories, given this is the only supported case? (This what has been done in the test of this PR)
- about URL normalization, which this PR has mostly move to settings, what should be done ?
This will mostly have impact on get_repo() and GIT_PREFIX
I will adjust this PR accordingly, but I need some decision and directions.
- should it assume that all http URLs are git repositories, given this is the only supported case? (This what has been done in the test of this PR)
- about URL normalization, which this PR has mostly move to settings, what should be done ?
IMO, it would be consistent to treat URLs identically when passed as a source to copier {copy,recopy} and when listed as trusted URLs in user settings. If you use the same logic as the Template.url_expanded property, then all HTTP and SSH URLs are treated as Git URLs, and if they can't be parsed using get_repo(), then the original URL is used as a fallback for, e.g., local paths. Off the top of my head, I can't think of a security problem when also normalizing the trusted URLs like this. And not normalizing trusted URLs, i.e. requiring a user to provide a normalized URL in the list of trusted URLs, feels brittle and unexpected by users.