At the time that github:// was added (5 years ago now?) git could not be counted upon to be installed by the folks who may be interested in depending upon a project hosted on github, so the tarball approach was used so that those brave souls interested in using git and github could do so without forcing everyone else�� to start using git ... nowadays with git becoming part of the mainstream dev env for Smalltalk, git (or libgit2 in the case of pharo) can be counted on to be available ...These days, we are getting to the point where I am beginning to flip the question on it's head and begin thinking that it should be possible for�� a developer to choose to have have the github:// url interpreted as "create a local clone of the remote repository" instead of "download a tarball of the remote repository" . With this approach it should be possible to include gitlab url support as well since the gitlab issue is related to the specific handling of repository tarballs..
Using�� 'git clone --depth=1'�� don't do the trick and leave the process both efficient and general accross all git repos?
On Tue, Dec 19, 2017 at 4:49 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
BitBucket is supported with like Github with: butbucket://<butbucket_path>/<srcpath>.
With regards to GitLab, their download zip format is/was different enough from BitBucket/Github to make it difficult to provide the same level of support. See the series of comments here[1].
When the github:// was first introduced it was done in such a way that users of projects on GitHub did not have to have git installed on their local computers ... it was a way to make it possible for folks to begin using git without requiring everyone to install git ...
These days, we are getting to the point where I am beginning to flip the question on it's head and begin thinking that it should be possible for�� a developer to choose to have have the github:// url interpreted as "create a local clone of the remote repository" instead of "download a tarball of the remote repository" . With this approach it should be possible to include gitlab url support as well since the gitlab issue is related to the specific handling of repository tarballs...
... there are current discussions in this area on these two issues [2] and [3].
Dale
[1] https://github.com/Metacello/metacello/issues/287#issuecomme nt-59815235
[2] https://github.com/Metacello/metacello/issues/474
[3] https://github.com/Metacello/metacello/issues/475
On 12/19/17 10:25 AM, Vitor Medina Cruz wrote:
Hello,
Using github://<github_path>/<srcpath> metacello works fine, but is there another more general way of refering to a remote git repo? From BitBucket or Gitlab for example.
Regards,
Vitor