Allow using specific revisions in lib install --git-url
(#1113)
#1776
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 is done by providing the desired revision in the fragment, e.g.
…/Library.git#0.1.0
. When set, this disables the clone depth limit soall remote references will be available.
This is part of what's discussed in #1113 (i.e. for raw library URLs - not for cores, and not for packaged libraries.)
Please check if the PR fulfills these requirements
before creating one)
our contributing guidelines
UPGRADING.md
has been updated with a migration guide (for breaking changes)Feature.
Installing a library via
--git-url
always installs the default remote branch's HEAD.A URL fragment may be used to identify a revision per the rules for go-git's
ResolveRevision
, e.g.https://github.com/arduino-libraries/WiFi101.git#master
orhttps://github.com/arduino-libraries/WiFi101.git#0.16.0
. The version currently used by arduino-cli supports branch, tag, and full SHAs; more recent versions would also support short SHAs.titled accordingly?
Mostly no, unless someone was passing a wrong fragment in their URLs already and expecting to be ignored. If they were, it will now print a message like
Other possible syntax would be
@ref
instead of#ref
. Based on other tools I use#ref
seems more common with purely URL-based specifications while@ref
is more common for not-really-URLs likego get
or package repositories. Since these are really URLs I've gone with#
.This is only supported on true URLs, not the
git@
or path variants, as it's not clear what character would be guaranteed to be unambiguous for these formats.I'm open to reconsidering both of these choices, as well as any additional testing ideas.