On 12/20/17 2:53 AM, Vitor Medina Cruz wrote:
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?
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 ...
On Tue, Dec 19, 2017 at 4:49 PM, Dale Henrichs
<dale.henri...@gemtalksystems.com
<mailto:dale.henri...@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#issuecomment-59815235
<https://github.com/Metacello/metacello/issues/287#issuecomment-59815235>
[2] https://github.com/Metacello/metacello/issues/474
<https://github.com/Metacello/metacello/issues/474>
[3] https://github.com/Metacello/metacello/issues/475
<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
