Basic versioning of GitHub repositories from within Pharo
Hi everyone, As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree. Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png <http://i.imgur.com/iMfWOvp.png> The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute: (ConfigurationOfGitHub project version: #development) load: #tool Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory. That is, thereâs no local copy on the filesystem. One does not even need git installed. That being said, feel free to take off with my prototype and make it work with e.g. the LibGit bindings in Pharo. Known bug: - When selecting a different repository from the dropdown while a version is also selected in the log, one gets a DNU. To work around this for the time being, just deselect the version before you switch repositories. Let me know what you think and feel free to ask some questions. Skip
On Mon, Nov 23, 2015 at 11:25 PM, Skip Lentz <skip.lentz@inria.fr> wrote:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo.
Sounds cool. Do you mean the REST api? Can you provide a link to the API docs? cheers -ben
As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory. That is, thereâs no local copy on the filesystem. One does not even need git installed.
That being said, feel free to take off with my prototype and make it work with e.g. the LibGit bindings in Pharo.
Known bug: - When selecting a different repository from the dropdown while a version is also selected in the log, one gets a DNU. To work around this for the time being, just deselect the version before you switch repositories.
Let me know what you think and feel free to ask some questions.
Skip
On Nov 23, 2015, at 4:34 PM, Ben Coman <btc@openinworld.com> wrote:
On Mon, Nov 23, 2015 at 11:25 PM, Skip Lentz <skip.lentz@inria.fr> wrote:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo.
Sounds cool. Do you mean the REST api? Can you provide a link to the API docs?
Yes, the REST API. Here you go: https://developer.github.com/v3/
The project can be loaded like this: Metacello new smalltalkhubUser: #Balletie project: #GitHub; configuration: #GitHub; version: #development; load: #tool
On 23 Nov 2015, at 16:37, Skip Lentz <skip.lentz@inria.fr> wrote:
On Nov 23, 2015, at 4:34 PM, Ben Coman <btc@openinworld.com> wrote:
On Mon, Nov 23, 2015 at 11:25 PM, Skip Lentz <skip.lentz@inria.fr> wrote:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo.
Sounds cool. Do you mean the REST api? Can you provide a link to the API docs?
Yes, the REST API. Here you go: https://developer.github.com/v3/
Is there any guide on how to use it? Iâve opened the tool, entered a username, left out the password field blank. Then I get nil exception because `self avatarUrl` of GHLoggedInUser returns nil. Cheers. Uko
On 23 Nov 2015, at 16:42, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
The project can be loaded like this:
Metacello new smalltalkhubUser: #Balletie project: #GitHub; configuration: #GitHub; version: #development; load: #tool
On 23 Nov 2015, at 16:37, Skip Lentz <skip.lentz@inria.fr> wrote:
On Nov 23, 2015, at 4:34 PM, Ben Coman <btc@openinworld.com> wrote:
On Mon, Nov 23, 2015 at 11:25 PM, Skip Lentz <skip.lentz@inria.fr> wrote:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo.
Sounds cool. Do you mean the REST api? Can you provide a link to the API docs?
Yes, the REST API. Here you go: https://developer.github.com/v3/
On Nov 23, 2015, at 4:46 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Is there any guide on how to use it? Iâve opened the tool, entered a username, left out the password field blank. Then I get nil exception because `self avatarUrl` of GHLoggedInUser returns nil.
Ah yes, that part might not be clear. The idea is that you can either enter a username and password, or enter an access token for the API and leave the password field blank. I wasnât really sure how to convey that in the UI, perhaps this made it even more vague. After youâve entered the login details, the repositories you own are loaded into the dropdown list and a log is shown with the last 25 commits (yes, itâs limited to that for now). One can then select a version and click checkout to load the packages listed on the right into the image. If all goes well you should see an arrow pointing at the currently loaded version in the list. After having done some changes, one can click commit which opens a Komitter window. (Committing is the least stable at the moment). It would be nice to be able to select and checkout versions without having to enter your username and password, but at the moment thatâs not supported..
I just committed a fix for when opening a repository with more than 25 commits (which is basically any repository). I already fixed this but did not commit it yet to the repository on smalltalkhub, oops.
On 23 Nov 2015, at 16:55, Skip Lentz <skip.lentz@inria.fr> wrote:
On Nov 23, 2015, at 4:46 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Is there any guide on how to use it? Iâve opened the tool, entered a username, left out the password field blank. Then I get nil exception because `self avatarUrl` of GHLoggedInUser returns nil.
Ah yes, that part might not be clear. The idea is that you can either enter a username and password, or enter an access token for the API and leave the password field blank. I wasnât really sure how to convey that in the UI, perhaps this made it even more vague.
After youâve entered the login details, the repositories you own are loaded into the dropdown list and a log is shown with the last 25 commits (yes, itâs limited to that for now).
Ok, when I enter a username and password, I get "receiver of asDateAndTime is nilâ in #setDateAndTimeMapping:. (should it work on Pharo 5?) Cheers. Uko
One can then select a version and click checkout to load the packages listed on the right into the image. If all goes well you should see an arrow pointing at the currently loaded version in the list. After having done some changes, one can click commit which opens a Komitter window. (Committing is the least stable at the moment).
It would be nice to be able to select and checkout versions without having to enter your username and password, but at the moment thatâs not supported..
On Nov 23, 2015, at 5:32 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 23 Nov 2015, at 16:55, Skip Lentz <skip.lentz@inria.fr> wrote:
On Nov 23, 2015, at 4:46 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Is there any guide on how to use it? Iâve opened the tool, entered a username, left out the password field blank. Then I get nil exception because `self avatarUrl` of GHLoggedInUser returns nil.
Ah yes, that part might not be clear. The idea is that you can either enter a username and password, or enter an access token for the API and leave the password field blank. I wasnât really sure how to convey that in the UI, perhaps this made it even more vague.
After youâve entered the login details, the repositories you own are loaded into the dropdown list and a log is shown with the last 25 commits (yes, itâs limited to that for now).
Ok, when I enter a username and password, I get "receiver of asDateAndTime is nilâ in #setDateAndTimeMapping:.
(should it work on Pharo 5?)
Hmm yes it should work in Pharo 5. I didnât get this error yet. Can you tell me what the receiver is of #setDateAndTimeMapping: when it occurs?
Hi Skip, The receiver is GHRepository. Cheers. Uko
On 23 Nov 2015, at 17:46, Skip Lentz <skip.lentz@inria.fr> wrote:
On Nov 23, 2015, at 5:32 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 23 Nov 2015, at 16:55, Skip Lentz <skip.lentz@inria.fr> wrote:
On Nov 23, 2015, at 4:46 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Is there any guide on how to use it? Iâve opened the tool, entered a username, left out the password field blank. Then I get nil exception because `self avatarUrl` of GHLoggedInUser returns nil.
Ah yes, that part might not be clear. The idea is that you can either enter a username and password, or enter an access token for the API and leave the password field blank. I wasnât really sure how to convey that in the UI, perhaps this made it even more vague.
After youâve entered the login details, the repositories you own are loaded into the dropdown list and a log is shown with the last 25 commits (yes, itâs limited to that for now).
Ok, when I enter a username and password, I get "receiver of asDateAndTime is nilâ in #setDateAndTimeMapping:.
(should it work on Pharo 5?)
Hmm yes it should work in Pharo 5. I didnât get this error yet. Can you tell me what the receiver is of #setDateAndTimeMapping: when it occurs?
On Nov 23, 2015, at 5:32 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Ok, when I enter a username and password, I get "receiver of asDateAndTime is nilâ in #setDateAndTimeMapping:.
I also debugged this and it appears to be a corner case for some repositories where the âpushed_atâ field is null for whatever reason. I did a commit which should fix this (It just checks if the field is nil).
Thanks Uko for trying Alexandre
Le 23 nov. 2015 à 13:32, Yuriy Tymchuk <yuriy.tymchuk@me.com> a écrit :
On 23 Nov 2015, at 16:55, Skip Lentz <skip.lentz@inria.fr> wrote:
On Nov 23, 2015, at 4:46 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Is there any guide on how to use it? Iâve opened the tool, entered a username, left out the password field blank. Then I get nil exception because `self avatarUrl` of GHLoggedInUser returns nil.
Ah yes, that part might not be clear. The idea is that you can either enter a username and password, or enter an access token for the API and leave the password field blank. I wasnât really sure how to convey that in the UI, perhaps this made it even more vague.
After youâve entered the login details, the repositories you own are loaded into the dropdown list and a log is shown with the last 25 commits (yes, itâs limited to that for now).
Ok, when I enter a username and password, I get "receiver of asDateAndTime is nilâ in #setDateAndTimeMapping:.
(should it work on Pharo 5?)
Cheers. Uko
One can then select a version and click checkout to load the packages listed on the right into the image. If all goes well you should see an arrow pointing at the currently loaded version in the list. After having done some changes, one can click commit which opens a Komitter window. (Committing is the least stable at the moment).
It would be nice to be able to select and checkout versions without having to enter your username and password, but at the moment thatâs not supported..
On Mon, Nov 23, 2015 at 04:25:28PM +0100, Skip Lentz wrote:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png <http://i.imgur.com/iMfWOvp.png>
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory.
Do you have any plans to eventually make a "Git Tool" out of it, rather than GitHub Tool? Why is it tied to GitHub in the first place? Are you planning to support some github-specific features like issue tracker, etc? Because not being able to have git repo localy is actually a hindrance and not a "nice side effect" (unless of course you are using git as monticello). Peter
On 23 Nov 2015, at 17:31, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Mon, Nov 23, 2015 at 04:25:28PM +0100, Skip Lentz wrote:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png <http://i.imgur.com/iMfWOvp.png>
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory.
Do you have any plans to eventually make a "Git Tool" out of it, rather than GitHub Tool?
Why is it tied to GitHub in the first place? Are you planning to support
I think that itâs tied to github because there are nice api. The goal is not to have a tool that helps you to work with git, but the one that allows you to browse git repos. This is a nice small project that can be a part of some larger one.
some github-specific features like issue tracker, etc? Because not being able to have git repo localy is actually a hindrance and not a "nice side effect" (unless of course you are using git as monticello).
Peter
On Nov 23, 2015, at 5:31 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Mon, Nov 23, 2015 at 04:25:28PM +0100, Skip Lentz wrote:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png <http://i.imgur.com/iMfWOvp.png>
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory.
Do you have any plans to eventually make a "Git Tool" out of it, rather than GitHub Tool?
Who knows, I like the idea of it. Again, itâs a prototype/demo/experiment of a versioning tool other than Monticello within Pharo. It didnât take much time to create, so I decided to just try it out.
Why is it tied to GitHub in the first place? Are you planning to support some github-specific features like issue tracker, etc? Because not being able to have git repo localy is actually a hindrance and not a "nice side effect" (unless of course you are using git as monticello).
For my project I needed to implement the API bindings to open pull requests. I saw this as another use case of the API and decided to experiment with it, thatâs all really.
Hi Skip, this is interesting. It would mean the ability to handle github issues querying/opening inside Pharo, no? Thierry Le 23/11/2015 16:25, Skip Lentz a écrit :
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory. That is, thereâs no local copy on the filesystem. One does not even need git installed.
That being said, feel free to take off with my prototype and make it work with e.g. the LibGit bindings in Pharo.
Known bug: - When selecting a different repository from the dropdown while a version is also selected in the log, one gets a DNU. To work around this for the time being, just deselect the version before you switch repositories.
Let me know what you think and feel free to ask some questions.
Skip
On Nov 23, 2015, at 6:32 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Skip,
this is interesting. It would mean the ability to handle github issues querying/opening inside Pharo, no?
Yes, if that part of the API is implemented. There are still a lot of extensions to be made. I am planning to implement the bindings for pull requests in the near future.
Le 23/11/2015 18:40, Skip Lentz a écrit :
On Nov 23, 2015, at 6:32 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Skip,
this is interesting. It would mean the ability to handle github issues querying/opening inside Pharo, no?
Yes, if that part of the API is implemented. There are still a lot of extensions to be made. I am planning to implement the bindings for pull requests in the near future.
It would be very cool to be able to envision a git + pharo combination where going on the github website wouldn't be necessary. Creating and commenting on an issue directly from inside Pharo instead of logging in fogbugz... Commenting on a commit from inside Pharo... Would you be able to retrieve the same information from github that GitFileTree does when it extract package version history information? Thierry
Hi thierry Skip is working on a code review tool :) and we decided after the experience of Griotte from thomas not to build our own again but interface with existing hence we chose git and github like tools. We want to support code review (publish metadata) on a publish code. Stef Le 23/11/15 18:55, Thierry Goubier a écrit :
Le 23/11/2015 18:40, Skip Lentz a écrit :
On Nov 23, 2015, at 6:32 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Skip,
this is interesting. It would mean the ability to handle github issues querying/opening inside Pharo, no?
Yes, if that part of the API is implemented. There are still a lot of extensions to be made. I am planning to implement the bindings for pull requests in the near future.
It would be very cool to be able to envision a git + pharo combination where going on the github website wouldn't be necessary.
Creating and commenting on an issue directly from inside Pharo instead of logging in fogbugz... Commenting on a commit from inside Pharo...
Would you be able to retrieve the same information from github that GitFileTree does when it extract package version history information?
Thierry
Yes, this is a cool project/approach. I personally love it that it does not require a plugin and/or library that might not exist on all platforms. Please keep going ! Sven
On 23 Nov 2015, at 18:32, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Skip,
this is interesting. It would mean the ability to handle github issues querying/opening inside Pharo, no?
Thierry
Le 23/11/2015 16:25, Skip Lentz a écrit :
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory. That is, thereâs no local copy on the filesystem. One does not even need git installed.
That being said, feel free to take off with my prototype and make it work with e.g. the LibGit bindings in Pharo.
Known bug: - When selecting a different repository from the dropdown while a version is also selected in the log, one gets a DNU. To work around this for the time being, just deselect the version before you switch repositories.
Let me know what you think and feel free to ask some questions.
Skip
Yes, keep going Alexandre
Le 23 nov. 2015 à 15:05, Sven Van Caekenberghe <sven@stfx.eu> a écrit :
Yes, this is a cool project/approach.
I personally love it that it does not require a plugin and/or library that might not exist on all platforms.
Please keep going !
Sven
On 23 Nov 2015, at 18:32, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Skip,
this is interesting. It would mean the ability to handle github issues querying/opening inside Pharo, no?
Thierry
Le 23/11/2015 16:25, Skip Lentz a écrit :
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory. That is, thereâs no local copy on the filesystem. One does not even need git installed.
That being said, feel free to take off with my prototype and make it work with e.g. the LibGit bindings in Pharo.
Known bug: - When selecting a different repository from the dropdown while a version is also selected in the log, one gets a DNU. To work around this for the time being, just deselect the version before you switch repositories.
Let me know what you think and feel free to ask some questions.
Skip
Very interesting ... if you put your project up on github, I would fork it and port it to tODE as this is something that has been on my todo list for awhile:) Dale On 11/23/2015 07:25 AM, Skip Lentz wrote:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub <http://smalltalkhub.com/#%21/%7EBalletie/GitHub> To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory. That is, thereâs no local copy on the filesystem. One does not even need git installed.
That being said, feel free to take off with my prototype and make it work with e.g. the LibGit bindings in Pharo.
Known bug: - When selecting a different repository from the dropdown while a version is also selected in the log, one gets a DNU. To work around this for the time being, just deselect the version before you switch repositories.
Let me know what you think and feel free to ask some questions.
Skip
Awesome, I'll use it soon :) On 23/11/15 16:25, Skip Lentz wrote:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png <http://i.imgur.com/iMfWOvp.png>
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory. That is, thereâs no local copy on the filesystem. One does not even need git installed.
That being said, feel free to take off with my prototype and make it work with e.g. the LibGit bindings in Pharo.
Known bug: - When selecting a different repository from the dropdown while a version is also selected in the log, one gets a DNU. To work around this for the time being, just deselect the version before you switch repositories.
Let me know what you think and feel free to ask some questions.
Skip
Hi Skip, Trying here, especially interested to see how it handles metadata-less filetree. - I have no authentification issues (but I had the feeling the GUI wasn't working for a little while) - I don't get all my repositories (well, in practice allmost none, however I get all the pharo books), so I can't test that metadata-less. - I get NeoJSON parser errors. Nice to see that nice graph widget put to good use :) But it could have less white space on the left. Now, how do I contribute if I want to? Where is the repository I should fork on github? I'm also a taker for a few more comments... Thierry 2015-11-23 16:25 GMT+01:00 Skip Lentz <skip.lentz@inria.fr>:
Hi everyone,
As part of my internship I am creating bindings to the GitHub API in Pharo. As a prototype and demo, I have created a small tool last week to do some basic versioning, namely checking out a version, committing a version and showing a log of commits along with a branch tree.
Hereâs a screenshot: http://i.imgur.com/iMfWOvp.png
The repository of the bindings and the tool is here: http://smalltalkhub.com/#!/~Balletie/GitHub To load the tool into your image, execute:
(ConfigurationOfGitHub project version: #development) load: #tool
Keep in mind that this is tied to GitHub, since internally it uses the API. A nice side effect of this is that everything can be done in-memory. That is, thereâs no local copy on the filesystem. One does not even need git installed.
That being said, feel free to take off with my prototype and make it work with e.g. the LibGit bindings in Pharo.
Known bug: - When selecting a different repository from the dropdown while a version is also selected in the log, one gets a DNU. To work around this for the time being, just deselect the version before you switch repositories.
Let me know what you think and feel free to ask some questions.
Skip
What I would like for Pharo is to avoid to be bound to a given back-end for its versionning. This master is a step in the right direction http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_5... Stef
And there lies the trap. If you end up making something that works with everything, you will create something that just works with everything instead of something that works very well with one thing. Right now Git is by very far the undisputed king of version control and has completely dethroned SVN. Ironically the things that make git integration in pharo so hard is all the thing that are there to decouple it from git , like filetree metadata , or continuous support for mcz and monticello. In the end you cant have your cake and eat it too. We will have to choose between very good integration with git or average / mediocre integration with multiple backends. On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo@free.fr> wrote:
What I would like for Pharo is to avoid to be bound to a given back-end for its versionning. This master is a step in the right direction
http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_5...
Stef
Hi, Le 29 nov. 2015 à 20:00, Dimitris Chloupis a écrit :
And there lies the trap.
If you end up making something that works with everything, you will create something that just works with everything instead of something that works very well with one thing.
could be. But we do not want to plug everything. Just having the door opened for the next cool VCS. Even if is only used for git it is good to have a Pharo API that is not the GIT API. We do not want git calls mixed everywhere. We want a clean and clear API for versioning. This API also prevents you from git API changes. You will only have one place to update and so on.
Right now Git is by very far the undisputed king of version control and has completely dethroned SVN.
King because widely used but other are also as valuable if not more.
Ironically the things that make git integration in pharo so hard is all the thing that are there to decouple it from git , like filetree metadata , or continuous support for mcz and monticello.
I do not agree on this point. There is no VCS interoperability layer in Pharo. Tools are directly manipulating Monticello.
In the end you cant have your cake and eat it too. We will have to choose between very good integration with git or average / mediocre integration with multiple backends.
again, I cannot agree. It is a bad idea to have calls to an external tool / library wide spread in the image. We need our own API. It is particularly true for git that has an API mixing daily tasks with other power admin commands (rewrite of the history with possible code loss). I do not think we need full support of git in the image, i.e. supporting all commands and options, but only what is needed to do correct versioning from Pharo (special git commands can still be done with command-line).
On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo@free.fr> wrote: What I would like for Pharo is to avoid to be bound to a given back-end for its versionning. This master is a step in the right direction
http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_5...
Stef
+ 1 It is about abstraction. Le 30/11/15 10:06, Christophe Demarey a écrit :
Hi,
Le 29 nov. 2015 à 20:00, Dimitris Chloupis a écrit :
And there lies the trap.
If you end up making something that works with everything, you will create something that just works with everything instead of something that works very well with one thing.
could be. But we do not want to plug everything. Just having the door opened for the next cool VCS. Even if is only used for git it is good to have a Pharo API that is not the GIT API. We do not want git calls mixed everywhere. We want a clean and clear API for versioning. This API also prevents you from git API changes. You will only have one place to update and so on.
Right now Git is by very far the undisputed king of version control and has completely dethroned SVN.
King because widely used but other are also as valuable if not more.
Ironically the things that make git integration in pharo so hard is all the thing that are there to decouple it from git , like filetree metadata , or continuous support for mcz and monticello.
I do not agree on this point. There is no VCS interoperability layer in Pharo. Tools are directly manipulating Monticello.
In the end you cant have your cake and eat it too. We will have to choose between very good integration with git or average / mediocre integration with multiple backends.
again, I cannot agree. It is a bad idea to have calls to an external tool / library wide spread in the image. We need our own API. It is particularly true for git that has an API mixing daily tasks with other power admin commands (rewrite of the history with possible code loss). I do not think we need full support of git in the image, i.e. supporting all commands and options, but only what is needed to do correct versioning from Pharo (special git commands can still be done with command-line).
On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
What I would like for Pharo is to avoid to be bound to a given back-end for its versionning. This master is a step in the right direction
http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_5...
Stef
Hi, On 29/11/15 14:00, Dimitris Chloupis wrote:
And there lies the trap.
If you end up making something that works with everything, you will create something that just works with everything instead of something that works very well with one thing. Right now Git is by very far the undisputed king of version control and has completely dethroned SVN.
If wisdom of the crowds were the wise path to follow, nobody would be using Pharo/Smalltalk. The kingdom of git is because of popularity, not from any particular technical superiority. Despite of its popularity, I have been able to keep myself away from git/GitHub, using them only for cloning and bug reporting, but for everything else I use fossil, a tool that tries to be out of my way and doesn't mess a lot with my workflow (a big difference with git) and keep metadata (bug reporting, wikis, conversations) with me instead of using it for making me depend on Central Server Inc. (a big difference with GitHub). I agree with Christophe and Steph on this and is nice to have people making this researching. A very welcomed work. Cheers, Offray
Well, personally, I far prefer Mercurial. Which also dethroned SVN. Mercurial has all the power of Git, while providing a more usable API. My mind works like a Smalltalker's, not like Linus's. It's true, some of the more abstruse functions of git require a longer chain of user actions in Mercurial in order to achieve the same end. But typically, the more common functions are more memorable in Mercurial than in git, and my typical use-cases for a DSCM system are less involved than that of the Linux core. On 29 November 2015 at 19:00, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
And there lies the trap.
If you end up making something that works with everything, you will create something that just works with everything instead of something that works very well with one thing. Right now Git is by very far the undisputed king of version control and has completely dethroned SVN.
Ironically the things that make git integration in pharo so hard is all the thing that are there to decouple it from git , like filetree metadata , or continuous support for mcz and monticello.
In the end you cant have your cake and eat it too. We will have to choose between very good integration with git or average / mediocre integration with multiple backends.
On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo@free.fr> wrote:
What I would like for Pharo is to avoid to be bound to a given back-end for its versionning. This master is a step in the right direction
http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_5...
Stef
We want a system of small objects with loose-coupling, and simple webs of message-sends. This allows us power, flexibility, maintainability *and* the opportunity to accommodate new requirements. We always need to bear this in mind. Build for the inevitable changes of environment and changes of requirement. You Ain't Gonna Need it (YAGNI) is often true, but well-factored code is *always* good. On 30 November 2015 at 17:02, EuanM <euanmee@gmail.com> wrote:
Well, personally, I far prefer Mercurial. Which also dethroned SVN.
Mercurial has all the power of Git, while providing a more usable API. My mind works like a Smalltalker's, not like Linus's.
It's true, some of the more abstruse functions of git require a longer chain of user actions in Mercurial in order to achieve the same end. But typically, the more common functions are more memorable in Mercurial than in git, and my typical use-cases for a DSCM system are less involved than that of the Linux core.
On 29 November 2015 at 19:00, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
And there lies the trap.
If you end up making something that works with everything, you will create something that just works with everything instead of something that works very well with one thing. Right now Git is by very far the undisputed king of version control and has completely dethroned SVN.
Ironically the things that make git integration in pharo so hard is all the thing that are there to decouple it from git , like filetree metadata , or continuous support for mcz and monticello.
In the end you cant have your cake and eat it too. We will have to choose between very good integration with git or average / mediocre integration with multiple backends.
On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo@free.fr> wrote:
What I would like for Pharo is to avoid to be bound to a given back-end for its versionning. This master is a step in the right direction
http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_5...
Stef
let me give you the thinking of someone that comes from another language "What is this ? Ah Pharo What features it has ? Ah thats some nice cool features, live coding looks sweet How about version control ? Hmm no its too weak and their website for hosting repos is problematic in many cases Maybe I could use git which I am familiar with ? Ah yes.... but wait there are many limitations How about big repos that git excels at ? Nope it crashes Pharo VM. Hmm.. ok Pharo looks like nice toy .... will go back to my language of choice and use it from time to time for foolish experiments. Notice one thing here, the user never cares about the flexibility of the API. Bottom line its not about git, or mecurial, or svn. Its about giving something that the user can use and right now when it comes to version control Pharo is light years behind. Things get popular not because they have nicely designed APIs, they become popular and rightly so and wisely so because they work. Simple as that. I hope at last version control is addressed seriously because its a real pity Pharo not to be able to use git when there are toy languages like brainfuck that interface better with it or other version control system. I am not against the idea of an abstraction API for Version Control , great idea do that, but first let get things working properly so we dont get people scratching their heads on git merges or people struggling to find out why sthub is down once again. On Mon, Nov 30, 2015 at 7:07 PM EuanM <euanmee@gmail.com> wrote:
We want a system of small objects with loose-coupling, and simple webs of message-sends. This allows us power, flexibility, maintainability *and* the opportunity to accommodate new requirements.
We always need to bear this in mind. Build for the inevitable changes of environment and changes of requirement. You Ain't Gonna Need it (YAGNI) is often true, but well-factored code is *always* good.
On 30 November 2015 at 17:02, EuanM <euanmee@gmail.com> wrote:
Well, personally, I far prefer Mercurial. Which also dethroned SVN.
Mercurial has all the power of Git, while providing a more usable API. My mind works like a Smalltalker's, not like Linus's.
It's true, some of the more abstruse functions of git require a longer chain of user actions in Mercurial in order to achieve the same end. But typically, the more common functions are more memorable in Mercurial than in git, and my typical use-cases for a DSCM system are less involved than that of the Linux core.
On 29 November 2015 at 19:00, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
And there lies the trap.
If you end up making something that works with everything, you will create something that just works with everything instead of something that works very well with one thing. Right now Git is by very far the undisputed king of version control and has completely dethroned SVN.
Ironically the things that make git integration in pharo so hard is all the thing that are there to decouple it from git , like filetree metadata , or continuous support for mcz and monticello.
In the end you cant have your cake and eat it too. We will have to choose between very good integration with git or average / mediocre integration with multiple backends.
On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo@free.fr> wrote:
What I would like for Pharo is to avoid to be bound to a given back-end for its versionning. This master is a step in the right direction
http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_5...
Stef
just for the usual note, thats my personal opinion and in no way try to discourage people just offer a different perspective to this. I always welcome any effort to improve pharo in any way, even for ways I dont care about so much. So keep up the amazing work you guys are doing with Pharo. On Mon, Nov 30, 2015 at 7:34 PM Dimitris Chloupis <kilon.alios@gmail.com> wrote:
let me give you the thinking of someone that comes from another language
"What is this ? Ah Pharo What features it has ? Ah thats some nice cool features, live coding looks sweet How about version control ? Hmm no its too weak and their website for hosting repos is problematic in many cases Maybe I could use git which I am familiar with ? Ah yes.... but wait there are many limitations How about big repos that git excels at ? Nope it crashes Pharo VM.
Hmm.. ok Pharo looks like nice toy .... will go back to my language of choice and use it from time to time for foolish experiments. Notice one thing here, the user never cares about the flexibility of the API. Bottom line its not about git, or mecurial, or svn. Its about giving something that the user can use and right now when it comes to version control Pharo is light years behind.
Things get popular not because they have nicely designed APIs, they become popular and rightly so and wisely so because they work. Simple as that.
I hope at last version control is addressed seriously because its a real pity Pharo not to be able to use git when there are toy languages like brainfuck that interface better with it or other version control system.
I am not against the idea of an abstraction API for Version Control , great idea do that, but first let get things working properly so we dont get people scratching their heads on git merges or people struggling to find out why sthub is down once again.
On Mon, Nov 30, 2015 at 7:07 PM EuanM <euanmee@gmail.com> wrote:
We want a system of small objects with loose-coupling, and simple webs of message-sends. This allows us power, flexibility, maintainability *and* the opportunity to accommodate new requirements.
We always need to bear this in mind. Build for the inevitable changes of environment and changes of requirement. You Ain't Gonna Need it (YAGNI) is often true, but well-factored code is *always* good.
On 30 November 2015 at 17:02, EuanM <euanmee@gmail.com> wrote:
Well, personally, I far prefer Mercurial. Which also dethroned SVN.
Mercurial has all the power of Git, while providing a more usable API. My mind works like a Smalltalker's, not like Linus's.
It's true, some of the more abstruse functions of git require a longer chain of user actions in Mercurial in order to achieve the same end. But typically, the more common functions are more memorable in Mercurial than in git, and my typical use-cases for a DSCM system are less involved than that of the Linux core.
On 29 November 2015 at 19:00, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
And there lies the trap.
If you end up making something that works with everything, you will create something that just works with everything instead of something that works very well with one thing. Right now Git is by very far the undisputed king of version control and has completely dethroned SVN.
Ironically the things that make git integration in pharo so hard is all the thing that are there to decouple it from git , like filetree metadata , or continuous support for mcz and monticello.
In the end you cant have your cake and eat it too. We will have to choose between very good integration with git or average / mediocre integration with multiple backends.
On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo@free.fr> wrote:
What I would like for Pharo is to avoid to be bound to a given
back-end
for its versionning. This master is a step in the right direction
http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_5...
Stef
Hi, On 30/11/15 12:34, Dimitris Chloupis wrote:
let me give you the thinking of someone that comes from another language
"What is this ? Ah Pharo What features it has ? Ah thats some nice cool features, live coding looks sweet How about version control ? Hmm no its too weak and their website for hosting repos is problematic in many cases Maybe I could use git which I am familiar with ? Ah yes.... but wait there are many limitations How about big repos that git excels at ? Nope it crashes Pharo VM.
Maybe I could use X because I'm familiar with is the proper argument if is not taken too far. Interface with the external world without a forceful coupling to X1 should be the approach.
Things get popular not because they have nicely designed APIs, they become popular and rightly so and wisely so because they work. Simple as that.
Considering that several things work in a particular domain (data bases, DVCS, etc) that seems reductive.
I hope at last version control is addressed seriously because its a real pity Pharo not to be able to use git when there are toy languages like brainfuck that interface better with it or other version control system.
I am not against the idea of an abstraction API for Version Control , great idea do that, but first let get things working properly so we dont get people scratching their heads on git merges or people struggling to find out why sthub is down once again.
With that approach we should get Oracle intimately coupled with Pharo before having Garage or any DB related advance. In fact I'm using NBSQLite for *my* own purposes and needs, but I don't plan it to be the default in the language/environment. May be because pharo goes beyond the language and has and integrated experience, we think in how we can make it smoother for other people, like frameworks which integrate git or sqlite by default, but a proper balance to not enforce my particular tastes over others should be kept also. So I would advice tightly integration for "apps" (Scratch, grafoscopio) and loose one for frameworks/environments (Aida, Seaside, and pharo itself). Cheers, Offray
Why could not I publish code to a fossil repo using the same "conceptual" commands than git? Same question for Mercurial. So we are talking about abstraction over low-level APIs. Basic engineering practices. This is what we are doing with Athens (do not expose Cairo to the complete system) OSwindow (do not expose SDL to the complete system). Pharo is not done (but people could do that but when I see that peopel were forced to reverse engineer the git protocol) to script git at least this is not our objectives. Our objectives of the mail I sent and the answers of christophe are - make sure that we can version our code - without be tight to a back-end Stef
participants (14)
-
Alexandre Bergel -
Ben Coman -
Christophe Demarey -
Dale Henrichs -
Dimitris Chloupis -
EuanM -
Julien Delplanque -
Offray Vladimir Luna Cárdenas -
Peter Uhnak -
Skip Lentz -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier -
Yuriy Tymchuk