If all Pharo projects were on GitHub...
Locked
123
123
 
|
… Pharo may be within the 30 most popular languages on Earth.
The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. I wish we had a nice Git integration. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
+1
On 27.09.2015 11:57, Alexandre Bergel wrote: > … Pharo may be within the 30 most popular languages on Earth. > The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. > > I wish we had a nice Git integration. > > Alexandre |
Re: If all Pharo projects were on GitHub...
|
In reply to this post by abergel
we have more than a nice Git integration. I have been using Github for my pharo project for over a year now without any issue, the last few months I have been using gitfiltree which is making it even easier. Definitely beats the alternatives .
On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel <[hidden email]> wrote: … Pharo may be within the 30 most popular languages on Earth. |
|
|
I have tried several times to use Git for my project. But I do not want to spend time on configuring .gitattribute and other configuration file. This does not go in the right direction I believe. Why is it easier to use git with Java than it is with Pharo?
Alexandre > On Sep 27, 2015, at 12:11 PM, Dimitris Chloupis <[hidden email]> wrote: > > we have more than a nice Git integration. I have been using Github for my pharo project for over a year now without any issue, the last few months I have been using gitfiltree which is making it even easier. Definitely beats the alternatives . > > On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel <[hidden email]> wrote: > … Pharo may be within the 30 most popular languages on Earth. > The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. > > I wish we had a nice Git integration. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: If all Pharo projects were on GitHub...
|
|
It isn't. It is actually very easy to use git. Time for a video :-) Expect that for tomorrow. Phil Le 27 sept. 2015 12:22, "Alexandre Bergel" <[hidden email]> a écrit :
I have tried several times to use Git for my project. But I do not want to spend time on configuring .gitattribute and other configuration file. This does not go in the right direction I believe. Why is it easier to use git with Java than it is with Pharo? |
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by abergel
This is the first time I read that one had to customise .gitattribute and other configurations to get git running with pharo. I have never needed to do any of those things, for me its just a matter of doing a single click, for installing gitfiletree. Then I add my git project like any other smalltalkhub project and manage it the same way via monticello. Maybe describe the exact issues you are having so others can help you out ? On Sun, Sep 27, 2015 at 1:22 PM Alexandre Bergel <[hidden email]> wrote: I have tried several times to use Git for my project. But I do not want to spend time on configuring .gitattribute and other configuration file. This does not go in the right direction I believe. Why is it easier to use git with Java than it is with Pharo? |
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by kilon.alios
Le 27/09/2015 12:11, Dimitris Chloupis a écrit :
> we have more than a nice Git integration. I have been using Github for > my pharo project for over a year now without any issue, the last few > months I have been using gitfiltree which is making it even easier. > Definitely beats the alternatives . > Hi! Did you try to use git on a big project with a team? Did you try to merge .st files ? I heard it's really annoying to merge files with meta informations on git. An other point is that git file tree will not work on Windows if we do not fix the problem of the stdio. And a lot of people out of the community use Windows, so this is not a issue we should forget. Most of the people I know in company use Windows, so if we want to attract people this problem need to be corrected. > On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel > <[hidden email] <mailto:[hidden email]>> wrote: > > … Pharo may be within the 30 most popular languages on Earth. > The 30th languages has 3,253 repository. There are 2,635 on > SmalltalkHub. > > I wish we had a nice Git integration. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > Cheers Cyril |
signature.asc (836 bytes) |
|
In reply to this post by abergel
Alex do you know git?
Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... Did you try to use sourcetree (the UI for git) to understand what I mean? So we cannot use git simply we have to propose a much nicer model on top of this assembly. Now you can systematicall save your code with monticello and automatically publish it to git. Esteban has a script for doing that. Stef > … Pharo may be within the 30 most popular languages on Earth. > The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. > > I wish we had a nice Git integration. > > Alexandre |
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by CyrilFerlicot
Le 27/09/2015 13:12, Ferlicot D. Cyril a écrit :
> Le 27/09/2015 12:11, Dimitris Chloupis a écrit : >> we have more than a nice Git integration. I have been using Github for >> my pharo project for over a year now without any issue, the last few >> months I have been using gitfiltree which is making it even easier. >> Definitely beats the alternatives . >> > > Hi! > > Did you try to use git on a big project with a team? Did you try to > merge .st files ? > I heard it's really annoying to merge files with meta informations on git. > An other point is that git file tree will not work on Windows if we do > not fix the problem of the stdio. And a lot of people out of the > community use Windows, so this is not a issue we should forget. Most of > the people I know in company use Windows, so if we want to attract > people this problem need to be corrected. I'd really like people who put Windows as an important platform invest on making sure what we have for Windows support in Pharo really works. Thierry |
|
|
Coming back from africa I can say that windows is first then linux.....
and may be 1% mac >>> we have more than a nice Git integration. I have been using Github for >>> my pharo project for over a year now without any issue, the last few >>> months I have been using gitfiltree which is making it even easier. >>> Definitely beats the alternatives . >>> >> >> Hi! >> >> Did you try to use git on a big project with a team? Did you try to >> merge .st files ? >> I heard it's really annoying to merge files with meta informations on >> git. > >> An other point is that git file tree will not work on Windows if we do >> not fix the problem of the stdio. And a lot of people out of the >> community use Windows, so this is not a issue we should forget. Most of >> the people I know in company use Windows, so if we want to attract >> people this problem need to be corrected. > > I'd really like people who put Windows as an important platform invest > on making sure what we have for Windows support in Pharo really works. > > Thierry > > |
|
|
In reply to this post by stepharo
Hi,
I’ve been using git for all my projects since more than one year now, and frankly I found it really good… and the pull request mechanism is unbeatable. Now, what I do believe is that we need to improve a couple of things: 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative. 2) double commit is annoying. We have a decent solution for (2), gitfiletree but is not working fine in windows (and that’s mandatory). I would like a community push here to make it work fine. Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadn’t commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library). Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as “just another interchangeable repository for monticello”. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all. I worked in a replacement for filetree and as a file format it works fine… is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need. After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :) So I would do a “call for pushing” and ask community to spend some time making it work properly. cheers, Esteban > On 27 Sep 2015, at 13:43, stepharo <[hidden email]> wrote: > > Alex do you know git? > Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... > Did you try to use sourcetree (the UI for git) to understand what I mean? > So we cannot use git simply we have to propose a much nicer model on top of this assembly. > > Now you can systematicall save your code with monticello and automatically publish it to git. > Esteban has a script for doing that. > > Stef > >> … Pharo may be within the 30 most popular languages on Earth. >> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. >> >> I wish we had a nice Git integration. >> >> Alexandre > > |
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by stepharo
Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... Git allows you to do complex things if you need them. But you can easily use git without ever needing rebase, filter-branch or whatnot. Everything that Monticello can do can be done with git easily (commit, push, pull, merge). It just gives you much more powerful tools. |
|
|
In reply to this post by EstebanLM
On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <[hidden email]> wrote:
> Hi, > > I’ve been using git for all my projects since more than one year now, and frankly I found it really good… and the pull request mechanism is unbeatable. > Now, what I do believe is that we need to improve a couple of things: > > 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative. > 2) double commit is annoying. > > We have a decent solution for (2), gitfiletree but is not working fine in windows (and that’s mandatory). I would like a community push here to make it work fine. > Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadn’t commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library). Would moving to libgit2 bypass the problem with stdio? > Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as “just another interchangeable repository for monticello”. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all. > I worked in a replacement for filetree and as a file format it works fine… is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need. I have a vague recollection that the problem was a particular file where data changed each commit and having the idea that this might be solved by: each commit writing metadata to a different file e.g. NNNN.metadata, and Monticello knows to pick up the highest numbered metadata. > After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :) > > So I would do a “call for pushing” and ask community to spend some time making it work properly. > > cheers, > Esteban > > >> On 27 Sep 2015, at 13:43, stepharo <[hidden email]> wrote: >> >> Alex do you know git? >> Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... Git is very flexible which implies complexity for newcomers to it. What is required on top of git is a "well defined" workflow. I see sometimes on this mail-list that people design their tools for flexibility since they don't want to *impose* a workflow on people, which is a commendable philosophy, but slows adoption by newcomers. It may be useful to define "this is *the* way its done here" , with the standard proviso that there may be missteps that need to be tuned. cheers -ben >> Did you try to use sourcetree (the UI for git) to understand what I mean? >> So we cannot use git simply we have to propose a much nicer model on top of this assembly. >> >> Now you can systematicall save your code with monticello and automatically publish it to git. >> Esteban has a script for doing that. >> >> Stef >> >>> … Pharo may be within the 30 most popular languages on Earth. >>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. >>> >>> I wish we had a nice Git integration. >>> >>> Alexandre >> >> > > |
Re: If all Pharo projects were on GitHub...
|
|
Currently working in a distributed team with multiple companies. We use git and also Phabricator for reviews which is really great. I cant think of *not* using a DVCS and features like git rebase in such an environment. Phil > |
|
|
In reply to this post by Ben Coman
> On 28 Sep 2015, at 04:27, Ben Coman <[hidden email]> wrote: > > On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <[hidden email]> wrote: >> Hi, >> >> I’ve been using git for all my projects since more than one year now, and frankly I found it really good… and the pull request mechanism is unbeatable. >> Now, what I do believe is that we need to improve a couple of things: >> >> 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative. >> 2) double commit is annoying. >> >> We have a decent solution for (2), gitfiletree but is not working fine in windows (and that’s mandatory). I would like a community push here to make it work fine. >> Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadn’t commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library). > > Would moving to libgit2 bypass the problem with stdio? Yes. We call out to libgit2 through NativeBoost. > >> Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as “just another interchangeable repository for monticello”. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all. >> I worked in a replacement for filetree and as a file format it works fine… is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need. > > I have a vague recollection that the problem was a particular file > where data changed each commit and having the idea that this might be > solved by: each commit writing metadata to a different file e.g. > NNNN.metadata, and Monticello knows to pick up the highest numbered > metadata. > > >> After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :) >> >> So I would do a “call for pushing” and ask community to spend some time making it work properly. >> >> cheers, >> Esteban >> >> >>> On 27 Sep 2015, at 13:43, stepharo <[hidden email]> wrote: >>> >>> Alex do you know git? >>> Because to me git is **really** complex. I do not talk about add push commit but rebase remote.... > > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. > > cheers -ben > > >>> Did you try to use sourcetree (the UI for git) to understand what I mean? >>> So we cannot use git simply we have to propose a much nicer model on top of this assembly. >>> >>> Now you can systematicall save your code with monticello and automatically publish it to git. >>> Esteban has a script for doing that. >>> >>> Stef >>> >>>> … Pharo may be within the 30 most popular languages on Earth. >>>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub. >>>> >>>> I wish we had a nice Git integration. >>>> >>>> Alexandre >>> >>> >> >> > |
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by Ben Coman
Le 28/09/2015 04:27, Ben Coman a écrit :
> > I have a vague recollection that the problem was a particular file > where data changed each commit and having the idea that this might be > solved by: each commit writing metadata to a different file e.g. > NNNN.metadata, and Monticello knows to pick up the highest numbered > metadata. Hum, I thought that as well, but in fact write the merge driver turned out as far better and simpler. Moreover, all type of data oriented files (ston, json, version) do not merge properly in git. So even Esteban saying he will use STON does not seems to solve the merge issue, unless he is planning something else. I do take in account we will have more metadata in the future, thanks to EPICEA, so we need a way to handle it. Merging is easy, you just need to hook into it. I believed also that we could do the merge ourselves and force git to commit the result, but discovered this was a bad idea. Imagine having to fire Pharo to merge a 250k OCaml project with 2k of st code in it :( > Git is very flexible which implies complexity for newcomers to it. > What is required on top of git is a "well defined" workflow. I see > sometimes on this mail-list that people design their tools for > flexibility since they don't want to *impose* a workflow on people, > which is a commendable philosophy, but slows adoption by newcomers. > It may be useful to define "this is *the* way its done here" , with > the standard proviso that there may be missteps that need to be tuned. Unless you have some experience of Monticello, Metacello, the Pharo workflow, some of the workflow outside Pharo, and git, then defining this workflow is shooting in the dark. So, first attempts are either: - be flexible, so that you fit into a pre-existing workflow, and explore options, - be dictatorial in your shot in the dark, and pray you got it right. Now, we've solved all the hard points (apart from the Windows support), so we can imagine a future. Thierry |
|
|
In reply to this post by Peter Uhnak
Le 27/9/15 15:33, Peter Uhnák a écrit :
sure except that suddenly you do not know why you have to know the arcanes part. I think that git is not layered so you get exposed to a lot of details even when you avoid. May be having a set of git macros would help. Stef |
Re: If all Pharo projects were on GitHub...
|
|
2015-09-28 8:53 GMT+02:00 stepharo <[hidden email]>:
You probably nailed it when it comes to why git seems more complex that needs to be.
Maybe not because macros are fragile and your average set of git commands is rather limited. Making git simpler through Pharo could be nice... Thierry |
Re: If all Pharo projects were on GitHub...
|
|
Hmm, I don't see that, but I've been using git for many years so I am not in position to judge it how complex it is.
Maybe providing a way to streamline common patterns. For example in git community there's a well known workflow model http://nvie.com/posts/a-successful-git-branching-model/ There's even git extension (but you can still use git directly) on top of that pattern https://github.com/nvie/gitflow (better visualized here https://danielkummer.github.io/git-flow-cheatsheet/ ) And while most don't follow the pattern strictly, most people are at least inspired by it and adapt parts of it. Peter |
Re: If all Pharo projects were on GitHub...
|
|
In reply to this post by abergel
Alexandre Bergel <[hidden email]> writes: > I have tried several times to use Git for my project. But I do not > want to spend time on configuring .gitattribute and other > configuration file. This does not go in the right direction I believe. > Why is it easier to use git with Java than it is with Pharo? I disagree, I think configuring .gitattribute (for the merge driver) is an important step forward. It means that Pharo can control the merge. Currently, it's only useful for metadata. But later, it might be useful to facilitate code merges: e.g., a method is renamed in a branch and improved in another. This should not generate a conflict. With Epicea, we might be able to avoid this conflict in the future and drive the merge successfully. Another example: two branches each adds an instance variable to the same class. This should not generate a conflict. The merge driver could detect that and merge successfully. Final example: the merge driver could run the unit tests while merging to tell the developer when a merge is correct and when it is not. The merge driver means we can merge ASTs, not lines of source code. For me, the merge driver is the future, not the past. Thanks Thierry. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |