Hi, I continue the discussion here because I really would like to know the cons of using Git + Pharo.
From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere? - we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right? - Merging could be harder because it would rely on git tools? - opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo Thx for enlightening me, #Luc
Hi Luc, most of these problems are solved by gitfiletree by Goubier Thierry. It automatically commits the thing that you commit with Monticello, it allows you to push, and it shows you the history (sometimes a bit screwed, but good enough). ConfigurationOf works with GitHub projects, but I think there is also something in a new Metacello that I donât know about. Big con is that you essentially communicate with git through Monticello. And to doing advanced stuff, like a lot of branching, pull requests and so on, gives an impression that you are always hacking something. If you want to really work with git, you want to be able to have only git versions of your code, stage and commit certain changes, communicate with remote repos, and if something goes wrong talk to command line and deal with file-based pharo representation. But instead of this you have one more screen of Monticello + nasty metadata which complicates merging. Uko
On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
- Merging could be harder because it would rely on git tools?
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
Thx for enlightening me,
#Luc
Le 02/12/2014 17:13, Yuriy Tymchuk a écrit :
Hi Luc,
most of these problems are solved by gitfiletree by Goubier Thierry. It automatically commits the thing that you commit with Monticello, it allows you to push, and it shows you the history (sometimes a bit screwed, but good enough). ConfigurationOf works with GitHub projects, but I think there is also something in a new Metacello that I donât know about.
If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually).
Big con is that you essentially communicate with git through Monticello. And to doing advanced stuff, like a lot of branching, pull requests and so on, gives an impression that you are always hacking something.
I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it.
If you want to really work with git, you want to be able to have only git versions of your code, stage and commit certain changes, communicate with remote repos, and if something goes wrong talk to command line and deal with file-based pharo representation. But instead of this you have one more screen of Monticello + nasty metadata which complicates merging.
You need to use the merge driver for that, really. Ok, it requires a lot more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it. Thierry
Uko
On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
- Merging could be harder because it would rely on git tools?
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
Thx for enlightening me,
#Luc
On 02 Dec 2014, at 19:03, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 02/12/2014 17:13, Yuriy Tymchuk a écrit :
Hi Luc,
most of these problems are solved by gitfiletree by Goubier Thierry. It automatically commits the thing that you commit with Monticello, it allows you to push, and it shows you the history (sometimes a bit screwed, but good enough). ConfigurationOf works with GitHub projects, but I think there is also something in a new Metacello that I donât know about.
If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually).
Big con is that you essentially communicate with git through Monticello. And to doing advanced stuff, like a lot of branching, pull requests and so on, gives an impression that you are always hacking something.
I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it.
My problem is not in git, itâs in Monticello. Iâm used to be able to commit exactly what I want even if Iâve made more changes, Iâm used to make branches for each new feature and then merge it back⦠But I always have two versioning going on. I do things in git, and then I do things in monticello. Another problem is a real lack of features. Imagine if you could see a method blame from inside Pharo.
If you want to really work with git, you want to be able to have only git versions of your code, stage and commit certain changes, communicate with remote repos, and if something goes wrong talk to command line and deal with file-based pharo representation. But instead of this you have one more screen of Monticello + nasty metadata which complicates merging.
You need to use the merge driver for that, really. Ok, it requires a lot more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it.
Yes, but my main point is what when I merge, I donât care about monticello data⦠I already have a git version, why do I have to care about the ancestor of monticello version that became different because of cherrypicking. Again, Iâm not complaining. Iâm very glad that we have what we have now. Itâs just that I donât agree that git support is ready to be used by everyone. Because with git in general Iâm 10x more efficient than with git in Pharo. And with git in pharo itâs the same as with monticello, I just trade one problems for another ones. Uko
Thierry
Uko
On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
- Merging could be harder because it would rely on git tools?
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
Thx for enlightening me,
#Luc
Le 02/12/2014 20:41, Yuriy Tymchuk a écrit :
On 02 Dec 2014, at 19:03, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 02/12/2014 17:13, Yuriy Tymchuk a écrit :
Hi Luc,
most of these problems are solved by gitfiletree by Goubier Thierry. It automatically commits the thing that you commit with Monticello, it allows you to push, and it shows you the history (sometimes a bit screwed, but good enough). ConfigurationOf works with GitHub projects, but I think there is also something in a new Metacello that I donât know about.
If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually).
Big con is that you essentially communicate with git through Monticello. And to doing advanced stuff, like a lot of branching, pull requests and so on, gives an impression that you are always hacking something.
I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it.
My problem is not in git, itâs in Monticello. Iâm used to be able to commit exactly what I want even if Iâve made more changes, Iâm used to make branches for each new feature and then merge it back⦠But I always have two versioning going on. I do things in git, and then I do things in monticello. Another problem is a real lack of features.
Yes. I can understand that. It's very hard, in truth, to make that integration work. I'm cheating with Monticello in many places, just to reach that goal.
Imagine if you could see a method blame from inside Pharo.
That one would be real easy, in fact :) You just have to touch the GUI in Nautilus and add a command to GitFileTree (five or ten lines, no more). AltBrowser has one additional gui(s) which is triggered with gitfiletree support: a method version browser which is just like the normal one, except that it queries git for method versions in addition to the ones kept in the changes. Adding git blame access would be done in the same way.
If you want to really work with git, you want to be able to have only git versions of your code, stage and commit certain changes, communicate with remote repos, and if something goes wrong talk to command line and deal with file-based pharo representation. But instead of this you have one more screen of Monticello + nasty metadata which complicates merging.
You need to use the merge driver for that, really. Ok, it requires a lot more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it.
Yes, but my main point is what when I merge, I donât care about monticello data⦠I already have a git version, why do I have to care about the ancestor of monticello version that became different because of cherrypicking.
Hum. You'll need to give me an example because I don't know enough git to understand what you're saying. Do you mean that, if you merge in git, when reloaded in Pharo, it doesn't show you the right history? Or do you say that merging with Monticello doesn't appear correctly in git?
Again, Iâm not complaining. Iâm very glad that we have what we have now. Itâs just that I donât agree that git support is ready to be used by everyone. Because with git in general Iâm 10x more efficient than with git in Pharo. And with git in pharo itâs the same as with monticello, I just trade one problems for another ones.
Well, I guess that in both FileTree and GitFileTree visions, we went into close integration with the existing Monticello, with all the limitations inherent to that approach. Now, the question is how we make a better use of what we have access to. Thierry
On 02 Dec 2014, at 20:41, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2014, at 19:03, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 02/12/2014 17:13, Yuriy Tymchuk a écrit :
Hi Luc,
most of these problems are solved by gitfiletree by Goubier Thierry. It automatically commits the thing that you commit with Monticello, it allows you to push, and it shows you the history (sometimes a bit screwed, but good enough). ConfigurationOf works with GitHub projects, but I think there is also something in a new Metacello that I donât know about.
If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually).
Big con is that you essentially communicate with git through Monticello. And to doing advanced stuff, like a lot of branching, pull requests and so on, gives an impression that you are always hacking something.
I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it.
My problem is not in git, itâs in Monticello. Iâm used to be able to commit exactly what I want even if Iâve made more changes, Iâm used to make branches for each new feature and then merge it back⦠But I always have two versioning going on. I do things in git, and then I do things in monticello. Another problem is a real lack of features. Imagine if you could see a method blame from inside Pharo.
If you want to really work with git, you want to be able to have only git versions of your code, stage and commit certain changes, communicate with remote repos, and if something goes wrong talk to command line and deal with file-based pharo representation. But instead of this you have one more screen of Monticello + nasty metadata which complicates merging.
You need to use the merge driver for that, really. Ok, it requires a lot more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it.
Yes, but my main point is what when I merge, I donât care about monticello data⦠I already have a git version, why do I have to care about the ancestor of monticello version that became different because of cherrypicking.
And this is what we need to fix. We do not need this duplications, and also it makes a lot more difficult to work in several branchs, etc. Esteban
Again, Iâm not complaining. Iâm very glad that we have what we have now. Itâs just that I donât agree that git support is ready to be used by everyone. Because with git in general Iâm 10x more efficient than with git in Pharo. And with git in pharo itâs the same as with monticello, I just trade one problems for another ones.
Uko
Thierry
Uko
On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
- Merging could be harder because it would rely on git tools?
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
Thx for enlightening me,
#Luc
On Tue, Dec 2, 2014 at 11:58 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 02 Dec 2014, at 20:41, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Yes, but my main point is what when I merge, I donât care about monticello data⦠I already have a git version, why do I have to care about the ancestor of monticello version that became different because of cherrypicking.
And this is what we need to fix. We do not need this duplications, and also it makes a lot more difficult to work in several branchs, etc.
Use Thierry's merge tool and then ignore the monticello meta data ... I am always doing complex merges of all kinds and Thierry's tool takes care of keeping the monticello data consistent while I can manually deal with the "real conflicts". Until every project on SmalltalkHub has been converted to git, you will need the monticello meta data ... this is something that will not happen overnight ... Dale
On Tue, Dec 2, 2014 at 11:41 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2014, at 19:03, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 02/12/2014 17:13, Yuriy Tymchuk a écrit :
Hi Luc,
most of these problems are solved by gitfiletree by Goubier Thierry. It automatically commits the thing that you commit with Monticello, it allows you to push, and it shows you the history (sometimes a bit screwed, but good enough). ConfigurationOf works with GitHub projects, but I think there is also something in a new Metacello that I donât know about.
If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually).
Big con is that you essentially communicate with git through Monticello. And to doing advanced stuff, like a lot of branching, pull requests and so on, gives an impression that you are always hacking something.
I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it.
My problem is not in git, itâs in Monticello. Iâm used to be able to commit exactly what I want even if Iâve made more changes, Iâm used to make branches for each new feature and then merge it back⦠But I always have two versioning going on. I do things in git, and then I do things in monticello. Another problem is a real lack of features. Imagine if you could see a method blame from inside Pharo.
So *implement* it. At least in Monticello *you* can make a change and have it spread through the entire Squeak/Pharo community very quickly. You can't do that with git. Your criticisms of git+Monticello don't hold up in pure Monticello.
If you want to really work with git, you want to be able to have only git versions of your code, stage and commit certain changes, communicate with remote repos, and if something goes wrong talk to command line and deal with file-based pharo representation. But instead of this you have one more screen of Monticello + nasty metadata which complicates merging.
You need to use the merge driver for that, really. Ok, it requires a lot
more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it.
Yes, but my main point is what when I merge, I donât care about monticello data⦠I already have a git version, why do I have to care about the ancestor of monticello version that became different because of cherrypicking.
Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata. What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do. [and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
Again, Iâm not complaining. Iâm very glad that we have what we have now. Itâs just that I donât agree that git support is ready to be used by everyone. Because with git in general Iâm 10x more efficient than with git in Pharo. And with git in pharo itâs the same as with monticello, I just trade one problems for another ones.
Uko
Thierry
Uko
On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
- Merging could be harder because it would rely on git tools?
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
Thx for enlightening me,
#Luc
-- best, Eliot
2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata.
Eliot, you'll have to do better than just IMO on that one. Some of us work with *both*, and have code for going back and forth, so the *better*; bah. I also happens to know how long it takes to parse hundreds of monticello metadata files... and I wasn't impressed with the result.
What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do.
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
You then have noticed that those threads are about working on tools? Thierry
On Wed, Dec 3, 2014 at 7:25 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata.
Eliot, you'll have to do better than just IMO on that one.
Some of us work with *both*, and have code for going back and forth, so the *better*; bah.
The main issue I have (and I love MCZ to transfer projects around, it is super easy, especially to patch a running box without fuss). Now, the key problem are resource files. I am working on webapps, and you get javascript, assets (images, css, svgs, mo files, and, in the current project, other languages running the backend). It is just a pain to maintain mczs on one side and assets on another one and keeping it all in sync. So, the workflow is to save with filetree:// to have it all, but still keep and eye on the package-cache/ to pick mczs as needed. One important thing to note is that Monticello saves a new mcz with a nice author+number on each save where filetree:// writes over what is there. So, if one isn't careful, it is easy to overwrite. Mczs have saved my butt once or twice here. Kind of a backup mechanism. With Mczs, there is also this feeling of being closer to the versions as they are just there in the environment. Both tools have value, and the discussion shouldn't be on what replaces what, but on how to best complement each other. For the record, I use Thierry's merge driver and it makes things smoother. It took me a while before installing that. And after a couple months of solid git usage, I am still learning. That's a pain even if the result is nice. FWIW, I have been using a cool command line tool for most of my git work on servers: tig http://jonas.nitro.dk/tig/ (runs on ubuntu without problems, has some conflict with bash-completion on CentOS 6.5 but you can install). Try it with: tig show or tig status The keybindings are like vim (so: q will get you out of most screens). You do a tig status and use 'u' to stage/unstage along with j/k to move around (or arrows). d will give you the diff view, which you can exit with q This is the kind of tool we could bring into Pharo and, while not replacing Monticello, it would complement it magnificently. Phil
I also happens to know how long it takes to parse hundreds of monticello metadata files... and I wasn't impressed with the result.
What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do.
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
You then have noticed that those threads are about working on tools?
Thierry
On Wed, Dec 3, 2014 at 8:48 AM, phil@highoctane.be <phil@highoctane.be> wrote:
On Wed, Dec 3, 2014 at 7:25 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata.
Eliot, you'll have to do better than just IMO on that one.
Some of us work with *both*, and have code for going back and forth, so the *better*; bah.
The main issue I have (and I love MCZ to transfer projects around, it is super easy, especially to patch a running box without fuss).
Now, the key problem are resource files. I am working on webapps, and you get javascript, assets (images, css, svgs, mo files, and, in the current project, other languages running the backend). It is just a pain to maintain mczs on one side and assets on another one and keeping it all in sync.
So, the workflow is to save with filetree:// to have it all, but still keep and eye on the package-cache/ to pick mczs as needed.
One important thing to note is that Monticello saves a new mcz with a nice author+number on each save where filetree:// writes over what is there. So, if one isn't careful, it is easy to overwrite. Mczs have saved my butt once or twice here. Kind of a backup mechanism.
With Mczs, there is also this feeling of being closer to the versions as they are just there in the environment.
Both tools have value, and the discussion shouldn't be on what replaces what, but on how to best complement each other.
For the record, I use Thierry's merge driver and it makes things smoother. It took me a while before installing that. And after a couple months of solid git usage, I am still learning. That's a pain even if the result is nice.
FWIW, I have been using a cool command line tool for most of my git work on servers: tig http://jonas.nitro.dk/tig/ (runs on ubuntu without problems, has some conflict with bash-completion on CentOS 6.5 but you can install).
Try it with:
tig show
or
tig status
The keybindings are like vim (so: q will get you out of most screens).
You do a tig status and use 'u' to stage/unstage along with j/k to move around (or arrows).
d will give you the diff view, which you can exit with q
This is the kind of tool we could bring into Pharo and, while not replacing Monticello, it would complement it magnificently.
Little article on tig: http://blogs.atlassian.com/2013/05/git-tig/
Phil
I also happens to know how long it takes to parse hundreds of monticello metadata files... and I wasn't impressed with the result.
What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do.
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
You then have noticed that those threads are about working on tools?
Thierry
Hi Thierry, On Tue, Dec 2, 2014 at 10:25 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata.
Eliot, you'll have to do better than just IMO on that one.
Quite right. One benefit is that Monticello metadata, at least per-method time stamps, are available for introspection inside the image. Just today I was alerted of some bad code by a particular author and it was very convenient to read all the methods by that particular author, which helped me find another problem. I also like the free frorm of the middle of method timestamps; I can and do annotate with labels for specific refactorings. Another benefit is that Monticello is amenable for scripting much more easily than git. I've been working on the SPur bootstrap fro a while now. It is essentially complete. What the bootstrap does in Monticello is construct patched versions of four packages, substituting specific methods with replacements. Each patched package inherits both from its patched ancestor and the package that was patched (a ladder like structure). This allows Spur to keep up-to-date automatically w.r.t. Squeak trunk. I'm also delighted that work like Chris Muller's version server is out there. This is very nicely integrated to allow me to find out which package versions contain versions of a particular method or class definition. Some of us work with *both*, and have code for going back and forth, so the
*better*; bah.
I also happens to know how long it takes to parse hundreds of monticello metadata files... and I wasn't impressed with the result.
Yes, but this can be reengineered. Most things can be optimized. This could be with a little effort. What's needed is to generate and maintain momentum. That's what worries me about git integration. It's a slippery slope towards giving up Monticello and just using git. And git itself will one day be viewed as old-hat. Monticello should be easy to keep evolving. It's in Smalltalk few chrissake.
What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do.
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
You then have noticed that those threads are about working on tools?
Yes, and that's why I'm writing to the thread. I hope that work on integrating foreign file support, and integrating things like Chris Muller's version server continues in the Pharo community. More than anything I hope that Monticello remains a bridge between the Squeak and Pharo communities.
Thierry
-- best, Eliot
Hi Eliot, thanks for that mail. 2014-12-04 23:59 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Thierry,
On Tue, Dec 2, 2014 at 10:25 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata.
Eliot, you'll have to do better than just IMO on that one.
Quite right. One benefit is that Monticello metadata, at least per-method time stamps, are available for introspection inside the image. Just today I was alerted of some bad code by a particular author and it was very convenient to read all the methods by that particular author, which helped me find another problem. I also like the free frorm of the middle of method timestamps; I can and do annotate with labels for specific refactorings.
I believe Dale will tell you that git will give you the ability to select a particular author work on a per-line basis, per-file basis (method or class, then), etc... Interestingly, the ability to comment at the file level is provided by github (well, in fact, it's a bit finer grained than that: it's commenting on a change in a file which fits your use case particularly well). So this means we could probably do better there.
Another benefit is that Monticello is amenable for scripting much more easily than git. I've been working on the SPur bootstrap fro a while now. It is essentially complete. What the bootstrap does in Monticello is construct patched versions of four packages, substituting specific methods with replacements. Each patched package inherits both from its patched ancestor and the package that was patched (a ladder like structure). This allows Spur to keep up-to-date automatically w.r.t. Squeak trunk.
But this would also work over a git-based Monticello. And, as you describe it, it probably even been seen as a simple merge (it's a kind of by-hand merge you're doing, basically). This is one of the features I'm waiting Max for: the time he spent dealing with the low-level structure of the .git stuff(*) so that you can do exactly what you describe (or a Monticello merge) and commit that, and have it tracked as such. (*) Honestly, I didn't want to do it myself :(
I'm also delighted that work like Chris Muller's version server is out there. This is very nicely integrated to allow me to find out which package versions contain versions of a particular method or class definition.
I know that this version server exists, and I hoped that you would point it out, because I believe it is significant. Even if it is not usable in many professional settings, such as mine. As you probably do as well, I know what features are needed from such a server to make it distributed 'Ã la git'.
Some of us work with *both*, and have code for going back and forth, so
the *better*; bah.
I also happens to know how long it takes to parse hundreds of monticello metadata files... and I wasn't impressed with the result.
Yes, but this can be reengineered. Most things can be optimized. This could be with a little effort. What's needed is to generate and maintain momentum. That's what worries me about git integration. It's a slippery slope towards giving up Monticello and just using git. And git itself will one day be viewed as old-hat. Monticello should be easy to keep evolving. It's in Smalltalk few chrissake.
Hey! You're talking to the guy who spent time making sure his git infrastructure would look and feel perfectly like a normal Monticello repository :) But, having the on-demand version metadata, on-demand creation of a specific history version, the speed at which you sync a remote, the fact that you can commit locally and sync later, the fact that querying for method or class versions is a lot faster... those are things that one should consider when thinking of improving Monticello.
What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do.
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
You then have noticed that those threads are about working on tools?
Yes, and that's why I'm writing to the thread. I hope that work on integrating foreign file support, and integrating things like Chris Muller's version server continues in the Pharo community. More than anything I hope that Monticello remains a bridge between the Squeak and Pharo communities.
I entirely agree with that :) Thierry
Thierry
-- best, Eliot
Thierry Goubier wrote:
2014-12-04 23:59 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:
I'm also delighted that work like Chris Muller's version server is out there. This is very nicely integrated to allow me to find out which package versions contain versions of a particular method or class definition.
I know that this version server exists, and I hoped that you would point it out, because I believe it is significant. Even if it is not usable in many professional settings, such as mine.
My google fu didn't turn up anything on this in the first few pages. Could you provide a pointer? cheers -ben
On Fri, Dec 5, 2014 at 5:02 AM, Ben Coman <btc@openinworld.com> wrote:
Thierry Goubier wrote:
2014-12-04 23:59 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:
I'm also delighted that work like Chris Muller's version server is out there. This is very nicely integrated to allow me to find out which package versions contain versions of a particular method or class definition.
I know that this version server exists, and I hoped that you would point it out, because I believe it is significant. Even if it is not usable in many professional settings, such as mine.
My google fu didn't turn up anything on this in the first few pages. Could you provide a pointer?
http://forum.world.st/ANN-New-source-squeak-org-prototype-td4707006.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-September/173069... -- cheers, Eliot
Am 04.12.2014 um 23:59 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Thierry,
On Tue, Dec 2, 2014 at 10:25 PM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:
Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata.
Eliot, you'll have to do better than just IMO on that one.
Quite right. One benefit is that Monticello metadata, at least per-method time stamps, are available for introspection inside the image. Just today I was alerted of some bad code by a particular author and it was very convenient to read all the methods by that particular author, which helped me find another problem. I also like the free frorm of the middle of method timestamps; I can and do annotate with labels for specific refactorings.
Another benefit is that Monticello is amenable for scripting much more easily than git. I've been working on the SPur bootstrap fro a while now. It is essentially complete. What the bootstrap does in Monticello is construct patched versions of four packages, substituting specific methods with replacements. Each patched package inherits both from its patched ancestor and the package that was patched (a ladder like structure). This allows Spur to keep up-to-date automatically w.r.t. Squeak trunk.
I'm also delighted that work like Chris Muller's version server is out there. This is very nicely integrated to allow me to find out which package versions contain versions of a particular method or class definition.
Some of us work with *both*, and have code for going back and forth, so the *better*; bah.
I also happens to know how long it takes to parse hundreds of monticello metadata files... and I wasn't impressed with the result.
Yes, but this can be reengineered. Most things can be optimized. This could be with a little effort. What's needed is to generate and maintain momentum. That's what worries me about git integration. It's a slippery slope towards giving up Monticello and just using git. And git itself will one day be viewed as old-hat. Monticello should be easy to keep evolving. It's in Smalltalk few chrissake.
+1 Plus: Introducing libgit2 will put additional burden for VM ports. Also there is a constant trial to get functionality out of the VM and into the image. This would be the opposite: new responsibility for the VM. Regards Andreas
Hi eliot I would like to check the ressources addition to MC. In the past I tried to harvest the refactorings did by chris in MC but I failed because of lack of patience and time. Now can you tell a word about the version server? Stef
On Fri, Dec 5, 2014 at 7:31 PM, stepharo <stepharo@free.fr> wrote:
Hi eliot
I would like to check the ressources addition to MC. In the past I tried to harvest the refactorings did by chris in MC but I failed because of lack of patience and time. Now can you tell a word about the version server?
I think you should ask Chris. I'm just a happy consumer. I don't know how it works, except that there's an automatically updated database accessible via a server than responds to the version info queries from images. I've asked Chris whether that server could be replicated on one's own machine (so that e.g. one can work without a network) and he says that,, yes of course this can be done. So this looks to me like a good scheme. But Chris is it's designer and implementor. Ask him... -- best, Eliot
Guille did a first attempt to add external resources to Monticello. interested people should contact him (now he cannot work on it since he should finish his PhD). While I think that moving to use git is important we should also consider that we should not put all the eggs in the same basket and that the design decision of our solution should be able to not systematically rely on git. Stef
On 03 Dec 2014, at 08:18, stepharo <stepharo@free.fr> wrote:
Guille did a first attempt to add external resources to Monticello. interested people should contact him (now he cannot work on it since he should finish his PhD). While I think that moving to use git is important we should also consider that we should not put all the eggs in the same basket and that the design decision of our solution should be able to not systematically rely on git.
Well, in my opinion Pharo have to understand a concept of âversioning systemâ and then there should be different drivers for each system. Instead Pharo understands Monticello and we are writing drivers to convert Monticello things into other versioning systems (git at the moment). Again, Iâm not criticizing, but Luc asked about cons, so Iâm pointing them out: âwe are not there yetâ. Uko
Stef
On 03 Dec 2014, at 04:16, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 2, 2014 at 11:41 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
On 02 Dec 2014, at 19:03, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 02/12/2014 17:13, Yuriy Tymchuk a écrit :
Hi Luc,
most of these problems are solved by gitfiletree by Goubier Thierry. It automatically commits the thing that you commit with Monticello, it allows you to push, and it shows you the history (sometimes a bit screwed, but good enough). ConfigurationOf works with GitHub projects, but I think there is also something in a new Metacello that I donât know about.
If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually).
Big con is that you essentially communicate with git through Monticello. And to doing advanced stuff, like a lot of branching, pull requests and so on, gives an impression that you are always hacking something.
I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it.
My problem is not in git, itâs in Monticello. Iâm used to be able to commit exactly what I want even if Iâve made more changes, Iâm used to make branches for each new feature and then merge it back⦠But I always have two versioning going on. I do things in git, and then I do things in monticello. Another problem is a real lack of features. Imagine if you could see a method blame from inside Pharo.
So *implement* it. At least in Monticello *you* can make a change and have it spread through the entire Squeak/Pharo community very quickly. You can't do that with git. Your criticisms of git+Monticello don't hold up in pure Monticello.
Yes, true, but Monticello can be missing versions, and I donât want to work with not reliable data.
If you want to really work with git, you want to be able to have only git versions of your code, stage and commit certain changes, communicate with remote repos, and if something goes wrong talk to command line and deal with file-based pharo representation. But instead of this you have one more screen of Monticello + nasty metadata which complicates merging.
You need to use the merge driver for that, really. Ok, it requires a lot more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it.
Yes, but my main point is what when I merge, I donât care about monticello data⦠I already have a git version, why do I have to care about the ancestor of monticello version that became different because of cherrypicking.
Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata. What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do.
For me one of the worst problems is that Monticello remains the bag of zips. I can throw away some zips and it will not complain. What kind of history is that? Oh yes, there are no branches, which again can be implemented, but Iâd rather use something maintained by other people. Uko
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
Again, Iâm not complaining. Iâm very glad that we have what we have now. Itâs just that I donât agree that git support is ready to be used by everyone. Because with git in general Iâm 10x more efficient than with git in Pharo. And with git in pharo itâs the same as with monticello, I just trade one problems for another ones.
Uko
Thierry
Uko
On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse@gmail.com <mailto:luc.fabresse@gmail.com>> wrote:
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
- Merging could be harder because it would rely on git tools?
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
Thx for enlightening me,
#Luc
-- best, Eliot
On 03 Dec 2014, at 04:16, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Yes, but *I* care about the Monticello metadata. IMO its *better* than the git metadata. What's really lacking in Monticello is a) it's not high school so one can't preen in front of the world on github and b) it has no support for external files. Well, a) will be solved by growing up and b) can be solved by building the solution. I know what I'd rather do.
why is better? I need more than an opinion there, because my own opinion is that is the contrary :) Esteban
Eliot Miranda wrote:
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
So what we need is a native Smalltalk git ;) Yes I know... more work with limited resources, but native git its being done in other places... (not sure how successfully) Javascript https://github.com/creationix/js-git Java http://eclipse.org/jgit/ Haskall http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ https://github.com/vincenthz/hit Python https://www.samba.org/~jelmer/dulwich/ Perl https://metacpan.org/pod/Git::PurePerl
Le 03/12/2014 14:02, Ben Coman a écrit :
Eliot Miranda wrote:
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
So what we need is a native Smalltalk git ;)
We need a better-than-git Smalltalk thing :)
Yes I know... more work with limited resources, but native git its being done in other places... (not sure how successfully)
I can give you a head start. There is some Smalltalk code to reuse; it's called FileSystem-Git, or FS-Git. https://github.com/dalehenrich/FSGit https://github.com/theseion/fs-git http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git http://smalltalkhub.com/#!/~FileSystemGitDev/Git-FileSystem They do lack a bit of activity. Thierry
Javascript https://github.com/creationix/js-git
Haskall http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ https://github.com/vincenthz/hit
On 04.12.2014, at 07:24, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 03/12/2014 14:02, Ben Coman a écrit :
Eliot Miranda wrote:
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
So what we need is a native Smalltalk git ;)
We need a better-than-git Smalltalk thing :)
Yes I know... more work with limited resources, but native git its being done in other places... (not sure how successfully)
I can give you a head start. There is some Smalltalk code to reuse; it's called FileSystem-Git, or FS-Git.
https://github.com/dalehenrich/FSGit
https://github.com/theseion/fs-git
http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git http://smalltalkhub.com/#!/~FileSystemGitDev/Git-FileSystem
They do lack a bit of activity.
Thatâs because they should be superseded by the libgit2 bindings. This is the right repo: http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git <http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git> (the github version is outdated).
Thierry
Javascript https://github.com/creationix/js-git
Haskall http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ https://github.com/vincenthz/hit
2014-12-04 8:27 GMT+01:00 Max Leske <maxleske@gmail.com>:
On 04.12.2014, at 07:24, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 03/12/2014 14:02, Ben Coman a écrit :
Eliot Miranda wrote:
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
So what we need is a native Smalltalk git ;)
We need a better-than-git Smalltalk thing :)
Yes I know... more work with limited resources, but native git its being done in other places... (not sure how successfully)
I can give you a head start. There is some Smalltalk code to reuse; it's called FileSystem-Git, or FS-Git.
https://github.com/dalehenrich/FSGit
https://github.com/theseion/fs-git
http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git http://smalltalkhub.com/#!/~FileSystemGitDev/Git-FileSystem
They do lack a bit of activity.
That's because they should be superseded by the libgit2 bindings.
If I'm not mistaken, they originally were what Ben suggested: a complete git reimplementation in Smalltalk via a FileSystem abstraction layer. The Pharo "whole" export to github would be based on that work, along with that 'almost like FileTree, but not the same' file format. But correct me if I got that wrong.
This is the right repo: http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git (the github version is outdated).
Thanks for the reminder (and the hard work you're putting into the libgit2 bindings), Thierry
Thierry
Javascript https://github.com/creationix/js-git
Haskall http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ https://github.com/vincenthz/hit
On 04 Dec 2014, at 09:07, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-04 8:27 GMT+01:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 04.12.2014, at 07:24, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 03/12/2014 14:02, Ben Coman a écrit :
Eliot Miranda wrote:
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
So what we need is a native Smalltalk git ;)
We need a better-than-git Smalltalk thing :)
Yes I know... more work with limited resources, but native git its being done in other places... (not sure how successfully)
I can give you a head start. There is some Smalltalk code to reuse; it's called FileSystem-Git, or FS-Git.
https://github.com/dalehenrich/FSGit <https://github.com/dalehenrich/FSGit>
https://github.com/theseion/fs-git <https://github.com/theseion/fs-git>
http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git <http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git> http://smalltalkhub.com/#!/~FileSystemGitDev/Git-FileSystem <http://smalltalkhub.com/#!/~FileSystemGitDev/Git-FileSystem>
They do lack a bit of activity.
Thatâs because they should be superseded by the libgit2 bindings.
If I'm not mistaken, they originally were what Ben suggested: a complete git reimplementation in Smalltalk via a FileSystem abstraction layer. The Pharo "whole" export to github would be based on that work, along with that 'almost like FileTree, but not the same' file format.
But correct me if I got that wrong.
it was Camilloâs work/idea, not Benâs. and well, it was a great idea, but never more than an experiment. I wanted it too, but I didnât continue the work because it would be different from monticello and community has proved been refractory to ideas that goes further it. so I get back to the other idea (Yours, Max) which was made monticello work with git. It will not be complete, but it will be a start. not that I have had actually time to work on it, but I will continue Max work as soon as I can allocate some time. Esteban
This is the right repo: http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git <http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git> (the github version is outdated).
Thanks for the reminder (and the hard work you're putting into the libgit2 bindings),
Thierry
Thierry
Javascript https://github.com/creationix/js-git <https://github.com/creationix/js-git>
Java http://eclipse.org/jgit/ <http://eclipse.org/jgit/>
Haskall http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ <http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/> https://github.com/vincenthz/hit <https://github.com/vincenthz/hit>
Python https://www.samba.org/~jelmer/dulwich/ <https://www.samba.org/~jelmer/dulwich/>
Perl https://metacpan.org/pod/Git::PurePerl <https://metacpan.org/pod/Git::PurePerl>
On 04.12.2014, at 09:07, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-04 8:27 GMT+01:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 04.12.2014, at 07:24, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 03/12/2014 14:02, Ben Coman a écrit :
Eliot Miranda wrote:
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
So what we need is a native Smalltalk git ;)
We need a better-than-git Smalltalk thing :)
Yes I know... more work with limited resources, but native git its being done in other places... (not sure how successfully)
I can give you a head start. There is some Smalltalk code to reuse; it's called FileSystem-Git, or FS-Git.
https://github.com/dalehenrich/FSGit <https://github.com/dalehenrich/FSGit>
https://github.com/theseion/fs-git <https://github.com/theseion/fs-git>
http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git <http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git> http://smalltalkhub.com/#!/~FileSystemGitDev/Git-FileSystem <http://smalltalkhub.com/#!/~FileSystemGitDev/Git-FileSystem>
They do lack a bit of activity.
Thatâs because they should be superseded by the libgit2 bindings.
If I'm not mistaken, they originally were what Ben suggested: a complete git reimplementation in Smalltalk via a FileSystem abstraction layer.
The idea is great and works quite well. There are two problems however and they are the reasons I chose to go with bindings: - such an implementation is very hard to maintain and the chance of introducing bugs is just off the charts - performance and memory allocation need a lot of working around (and praying)
The Pharo "whole" export to github would be based on that work, along with that 'almost like FileTree, but not the same' file format.
Not quite. The export simply produces (FileTree) artifacts and writes them to disk. There is no hard dependency to FileSystem-Git (although that might have been the plan at some point).
But correct me if I got that wrong.
This is the right repo: http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git <http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git> (the github version is outdated).
Thanks for the reminder (and the hard work you're putting into the libgit2 bindings),
Thank you for your patience :)
Thierry
Thierry
Javascript https://github.com/creationix/js-git <https://github.com/creationix/js-git>
Java http://eclipse.org/jgit/ <http://eclipse.org/jgit/>
Haskall http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ <http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/> https://github.com/vincenthz/hit <https://github.com/vincenthz/hit>
Python https://www.samba.org/~jelmer/dulwich/ <https://www.samba.org/~jelmer/dulwich/>
Perl https://metacpan.org/pod/Git::PurePerl <https://metacpan.org/pod/Git::PurePerl>
Am 04.12.2014 um 07:24 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Le 03/12/2014 14:02, Ben Coman a écrit :
Eliot Miranda wrote:
[and apologies for being deliberately incendiary but I *hate* the movement away from tools in Squeak/Pharo. It is a movement towards stasis and death, and personally I'm enjoying life too much].
So what we need is a native Smalltalk git ;)
We need a better-than-git Smalltalk thing :)
+1 darcs anyone? Norbert
Yes I know... more work with limited resources, but native git its being done in other places... (not sure how successfully)
I can give you a head start. There is some Smalltalk code to reuse; it's called FileSystem-Git, or FS-Git.
https://github.com/dalehenrich/FSGit
https://github.com/theseion/fs-git
http://smalltalkhub.com/#!/~FileSystemGitDev/FileSystem-Git http://smalltalkhub.com/#!/~FileSystemGitDev/Git-FileSystem
They do lack a bit of activity.
Thierry
Javascript https://github.com/creationix/js-git
Haskall http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ https://github.com/vincenthz/hit
On 04 Dec 2014, at 09:24, Norbert Hartl <norbert@hartl.name> wrote:
We need a better-than-git Smalltalk thing :)
yeah, we need a lot of things. But who will put the bell on the cat's neck? just dreaming of what we *could* have will make us never have anything⦠is not that horizons are bad, they are needed to show the path to follow. But not to accept the small improvements in the name of some super-goal we are never close (because, of course, horizons move constantly) is prone to immobility. Esteban
"Iâm not sure we need to discuss that, since there already is FileSystem-Git which *is* an implementation of Git in Smalltalkt..." is ? really ? wow I am impressed I thought reimplementing git in smalltalk would be a huge effort. Pharo surprises me once more :) so the problem now is to build the tools on top of it to utilize git ? On Thu, Dec 4, 2014 at 11:00 AM, Max Leske <maxleske@gmail.com> wrote:
On 04.12.2014, at 09:47, kilon alios <kilon.alios@gmail.com> wrote:
What are the benefits that justify the effort to reimplementing git in smalltalk ?
Iâm not sure we need to discuss that, since there already is FileSystem-Git which *is* an implementation of Git in Smalltalkt...
On 04.12.2014, at 10:09, kilon alios <kilon.alios@gmail.com> wrote:
"Iâm not sure we need to discuss that, since there already is FileSystem-Git which *is* an implementation of Git in Smalltalkt..."
is ? really ? wow I am impressed I thought reimplementing git in smalltalk would be a huge effort. Pharo surprises me once more :)
Well, itâs not complete, far fromit actually. Git is huge⦠(also, see my response to Thierry)
so the problem now is to build the tools on top of it to utilize git ?
Yes, but the tools should use libgit2 bindings, not the Smalltalk implementation.
On Thu, Dec 4, 2014 at 11:00 AM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
On 04.12.2014, at 09:47, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:
What are the benefits that justify the effort to reimplementing git in smalltalk ?
Iâm not sure we need to discuss that, since there already is FileSystem-Git which *is* an implementation of Git in Smalltalkt...
"Well, itâs not complete, far fromit actually. Git is huge⦠(also, see my response to Thierry)" yes that sound more logical . "Yes, but the tools should use libgit2 bindings, not the Smalltalk implementation." that sounds even more logical too. I am asking those questions because at the moment I thought I was missing something. I read people discussing implementing git in Pharo like its a one man project while my understanding is that git is huge and probably even bigger than pharo itself and that the problems is trying to solve are far more complex than the existing version control system of Pharo. But I am far from expert on this. using libgit2 sounds to me like a logical evolution for Pharo.
2014-12-04 9:44 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 04 Dec 2014, at 09:24, Norbert Hartl <norbert@hartl.name> wrote:
We need a better-than-git Smalltalk thing :)
yeah, we need a lot of things. But who will put the bell on the cat's neck? just dreaming of what we *could* have will make us never have anything... is not that horizons are bad, they are needed to show the path to follow. But not to accept the small improvements in the name of some super-goal we are never close (because, of course, horizons move constantly) is prone to immobility.
Honestly, in that particular case, I really had the feeling for some time that Pharo had chosen the super-goal instead of the incremental improvement. It changed with the focus on libgit2, luckily :) If I want to troll again :):) (beware) I'm interested by the Nautilus vs OmniBrowser decision. I have an hypothesis that this decision has value for anything looking like a Moldable, Glamour-based, Browser . Because in my mind, the OB gui framework and Glamour are along the same lines, and the OB GUI framework was missing something which pushed Nautilus forward[1]. So, for those who have used OB and Nautilus, or are using Squeak (where OB is still in use) and Pharo, what do you think? [1] http://marianopeck.wordpress.com/2012/02/26/nautilus-the-reborn-of-the-syste... Thierry
Esteban
Hi, I think that most browsers produced in Samlltalk look remarkably similar to the original one which was developed 30 years ago [1], even though it clearly isn't the best possible solution. I would like to get to one that does not necessarily resemble the current one, and in the process uncover new ways of developing software. This is a longer goal we have with GT, and I would like to get to something tangible in Pharo 5. [1] http://www.tudorgirba.com/presentations/dx Cheers, Doru On Thu, Dec 4, 2014 at 5:17 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-04 9:44 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 04 Dec 2014, at 09:24, Norbert Hartl <norbert@hartl.name> wrote:
We need a better-than-git Smalltalk thing :)
yeah, we need a lot of things. But who will put the bell on the cat's neck? just dreaming of what we *could* have will make us never have anything⦠is not that horizons are bad, they are needed to show the path to follow. But not to accept the small improvements in the name of some super-goal we are never close (because, of course, horizons move constantly) is prone to immobility.
Honestly, in that particular case, I really had the feeling for some time that Pharo had chosen the super-goal instead of the incremental improvement. It changed with the focus on libgit2, luckily :)
If I want to troll again :):) (beware)
I'm interested by the Nautilus vs OmniBrowser decision. I have an hypothesis that this decision has value for anything looking like a Moldable, Glamour-based, Browser . Because in my mind, the OB gui framework and Glamour are along the same lines, and the OB GUI framework was missing something which pushed Nautilus forward[1]. So, for those who have used OB and Nautilus, or are using Squeak (where OB is still in use) and Pharo, what do you think?
[1] http://marianopeck.wordpress.com/2012/02/26/nautilus-the-reborn-of-the-syste...
Thierry
Esteban
-- www.tudorgirba.com "Every thing has its own flow"
On Tue, Dec 2, 2014 at 8:00 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
When using git, you do not need to use a ConfigurationOf as all of the packages are versioned together so it isn't necessary to track individual mcz package versions ... you only really need a baseline to specify package/project dependencies. Instead of a ConfigurationOf you use a BaselineOf which has a single baseline: method[1]. The baseline: method is like any other baseline, except it isn't necessary to explicitly specify a repo - the repo used for the packages is the same one as the BaselineOf was loaded from. To load a baseline from a github repo you use an expression like the following: Metacello new baseline: 'Cryptography'; repository: 'github://GsDevKit/Cryptography:master/repository'; load: #('Cryptography') The :master in the repo specification can the name of a branch (master branch in this case), a SHA, a tag, or a tag pattern (1.1.? will load tags 1.1.0, 1.1.1, 1.1.2, etc.). To load from a local git clone (filetree repo) you use something like the following: Metacello new baseline: 'Cryptography'; repository: 'filetree:///opt/git/Cryptography/repository'; load: #('Cryptography') [1] https://github.com/GsDevKit/Cryptography/blob/master/repository/BaselineOfCr...
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
In tODE I've wrapped a large chunk of the shell command line git api with Smalltalk ... tODE has it's own command line, so git commands can be run from within tODE on the command line. Other tools make calls to he Smalltalk api.
- Merging could be harder because it would rely on git tools?
When merging with git, you may be merging multiple packages plus doc files, etc., at once, so the tool required for merge must be built to work with git merge meta data ... there are external merge tools, but I built a merge tool in tODE that I actually prefer over the other available merge tools ...
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
This is actually an advantage ... when you have a local git clone, you control when and how projects are updated ... how many times have previously working build procedures suddenly stop working because someone has made a change to a configuration of a project? With local clones your environment is static and stable until you are ready to upgrade to a new version and then you do so in a controlled manner.
If you use a spec like 'github://GsDevKit/Cryptography:master/repository', you are really using the latest version of master branch (bleeding edge for a remote repo)...In theory you can "require" that all tests pass before a change is merged into the master branch (using pull requests and travis-ci). so using the latest master branch should always be "safe". Dale
I will digest that amount of info now ;-) I am still unclear on some parts for example nowadays I load a ConfigOf and then I open the repositories of the dependencies in MC to check if there are updates to be merged in. It seems that it will not be that simple with this new setup. I will give it a try. Thank you all! #Luc 2014-12-02 18:00 GMT+01:00 Dale Henrichs <dale.henrichs@gemtalksystems.com>:
On Tue, Dec 2, 2014 at 8:00 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
When using git, you do not need to use a ConfigurationOf as all of the packages are versioned together so it isn't necessary to track individual mcz package versions ... you only really need a baseline to specify package/project dependencies. Instead of a ConfigurationOf you use a BaselineOf which has a single baseline: method[1]. The baseline: method is like any other baseline, except it isn't necessary to explicitly specify a repo - the repo used for the packages is the same one as the BaselineOf was loaded from.
To load a baseline from a github repo you use an expression like the following:
Metacello new baseline: 'Cryptography'; repository: 'github://GsDevKit/Cryptography:master/repository'; load: #('Cryptography')
The :master in the repo specification can the name of a branch (master branch in this case), a SHA, a tag, or a tag pattern (1.1.? will load tags 1.1.0, 1.1.1, 1.1.2, etc.).
To load from a local git clone (filetree repo) you use something like the following:
Metacello new baseline: 'Cryptography'; repository: 'filetree:///opt/git/Cryptography/repository'; load: #('Cryptography')
[1] https://github.com/GsDevKit/Cryptography/blob/master/repository/BaselineOfCr...
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
In tODE I've wrapped a large chunk of the shell command line git api with Smalltalk ... tODE has it's own command line, so git commands can be run from within tODE on the command line. Other tools make calls to he Smalltalk api.
- Merging could be harder because it would rely on git tools?
When merging with git, you may be merging multiple packages plus doc files, etc., at once, so the tool required for merge must be built to work with git merge meta data ... there are external merge tools, but I built a merge tool in tODE that I actually prefer over the other available merge tools ...
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
This is actually an advantage ... when you have a local git clone, you control when and how projects are updated ... how many times have previously working build procedures suddenly stop working because someone has made a change to a configuration of a project? With local clones your environment is static and stable until you are ready to upgrade to a new version and then you do so in a controlled manner.
If you use a spec like 'github://GsDevKit/Cryptography:master/repository', you are really using the latest version of master branch (bleeding edge for a remote repo)...In theory you can "require" that all tests pass before a change is merged into the master branch (using pull requests and travis-ci). so using the latest master branch should always be "safe".
Dale
Le 02/12/2014 20:35, Luc Fabresse a écrit :
I will digest that amount of info now ;-) I am still unclear on some parts for example nowadays I load a ConfigOf and then I open the repositories of the dependencies in MC to check if there are updates to be merged in.
It seems that it will not be that simple with this new setup.
In a baselineOf + github scenario (github, gitfiletree, by hand git clone + filetree), you allways load the latest on the branch or tag, so it's not needed. If you need to update (changes on the central repository), then you pull (git pull) and you see the new available versions (only with gitfiletree). FileTree will only show you the top version of each package.
I will give it a try.
Tell us how it goes. We need to know! But I guess I should work on that Git and Pharo chapter ;) Thierry
Thank you all!
#Luc
2014-12-02 18:00 GMT+01:00 Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>>:
On Tue, Dec 2, 2014 at 8:00 AM, Luc Fabresse <luc.fabresse@gmail.com <mailto:luc.fabresse@gmail.com>> wrote:
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
When using git, you do not need to use a ConfigurationOf as all of the packages are versioned together so it isn't necessary to track individual mcz package versions ... you only really need a baseline to specify package/project dependencies. Instead of a ConfigurationOf you use a BaselineOf which has a single baseline: method[1]. The baseline: method is like any other baseline, except it isn't necessary to explicitly specify a repo - the repo used for the packages is the same one as the BaselineOf was loaded from.
To load a baseline from a github repo you use an expression like the following:
Metacello new baseline: 'Cryptography'; repository: 'github://GsDevKit/Cryptography:master/repository'; load: #('Cryptography')
The :master in the repo specification can the name of a branch (master branch in this case), a SHA, a tag, or a tag pattern (1.1.? will load tags 1.1.0, 1.1.1, 1.1.2, etc.).
To load from a local git clone (filetree repo) you use something like the following:
Metacello new baseline: 'Cryptography'; repository: 'filetree:///opt/git/Cryptography/repository'; load: #('Cryptography')
[1] https://github.com/GsDevKit/Cryptography/blob/master/repository/BaselineOfCr...
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
In tODE I've wrapped a large chunk of the shell command line git api with Smalltalk ... tODE has it's own command line, so git commands can be run from within tODE on the command line. Other tools make calls to he Smalltalk api.
- Merging could be harder because it would rely on git tools?
When merging with git, you may be merging multiple packages plus doc files, etc., at once, so the tool required for merge must be built to work with git merge meta data ... there are external merge tools, but I built a merge tool in tODE that I actually prefer over the other available merge tools ...
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
This is actually an advantage ... when you have a local git clone, you control when and how projects are updated ... how many times have previously working build procedures suddenly stop working because someone has made a change to a configuration of a project? With local clones your environment is static and stable until you are ready to upgrade to a new version and then you do so in a controlled manner.
If you use a spec like 'github://GsDevKit/Cryptography:master/repository', you are really using the latest version of master branch (bleeding edge for a remote repo)...In theory you can "require" that all tests pass before a change is merged into the master branch (using pull requests and travis-ci). so using the latest master branch should always be "safe".
Dale
On Tue, Dec 2, 2014 at 11:45 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
If you need to update (changes on the central repository), then you pull (git pull) and you see the new available versions (only with gitfiletree). FileTree will only show you the top version of each package.
This is an area where I prefer to use `git diff` and enter the territory of "git integration"... it is possible to use git to compare two different SHA's for a given package/project/class/method and it is possible to compare the in-image package/project/class/method with a particular. In my opinion, this is the area where one should break from the Monticello paradigm where the package is the sole versioned entity and expand the versioned universe to include project/package/class/method versions. There is also tremendous value to simply comparing two different git commits which may span multiple packages and include updates to documentation and other text files ... To view git through only the package model is too restrictive and limits some of the real power one can experience when using git ... Dale
Le 02/12/2014 20:59, Dale Henrichs a écrit :
On Tue, Dec 2, 2014 at 11:45 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
If you need to update (changes on the central repository), then you pull (git pull) and you see the new available versions (only with gitfiletree). FileTree will only show you the top version of each package.
This is an area where I prefer to use `git diff` and enter the territory of "git integration"... it is possible to use git to compare two different SHA's for a given package/project/class/method and it is possible to compare the in-image package/project/class/method with a particular.
But both approaches are allowing you that. What GitFileTree shows you is the git commit history, filtered by packages... and you can diff, as well, whether its by package/project/class/method, or simply explore the history from the point of view of the entity your focusing on (well, ok, no project...).
In my opinion, this is the area where one should break from the Monticello paradigm where the package is the sole versioned entity and expand the versioned universe to include project/package/class/method versions. There is also tremendous value to simply comparing two different git commits which may span multiple packages and include updates to documentation and other text files ...
Yes, the project on top. I think this is something Phil has been saying as well, and I'm sure this is something which will be added, once Pharo will focus on that. But I'll check first if some projects (I'm thinking say a compiler of which pharo is just the front-end, i.e. over 100 000lines of which 90% is C code) won't end up being too large. Nothing we can't solve with appropriate tools.
To view git through only the package model is too restrictive and limits some of the real power one can experience when using git ...
This was the limitation of working within Monticello. Now that the infrastructure is there, we can (we should) do better. Thierry
Agreed! On Tue, Dec 2, 2014 at 12:15 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 02/12/2014 20:59, Dale Henrichs a écrit :
On Tue, Dec 2, 2014 at 11:45 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
If you need to update (changes on the central repository), then you pull (git pull) and you see the new available versions (only with gitfiletree). FileTree will only show you the top version of each package.
This is an area where I prefer to use `git diff` and enter the territory of "git integration"... it is possible to use git to compare two different SHA's for a given package/project/class/method and it is possible to compare the in-image package/project/class/method with a particular.
But both approaches are allowing you that. What GitFileTree shows you is the git commit history, filtered by packages... and you can diff, as well, whether its by package/project/class/method, or simply explore the history from the point of view of the entity your focusing on (well, ok, no project...).
In my opinion, this is the area where one should break from the
Monticello paradigm where the package is the sole versioned entity and expand the versioned universe to include project/package/class/method versions. There is also tremendous value to simply comparing two different git commits which may span multiple packages and include updates to documentation and other text files ...
Yes, the project on top. I think this is something Phil has been saying as well, and I'm sure this is something which will be added, once Pharo will focus on that.
But I'll check first if some projects (I'm thinking say a compiler of which pharo is just the front-end, i.e. over 100 000lines of which 90% is C code) won't end up being too large. Nothing we can't solve with appropriate tools.
To view git through only the package model is too restrictive and limits
some of the real power one can experience when using git ...
This was the limitation of working within Monticello.
Now that the infrastructure is there, we can (we should) do better.
Thierry
I think its great that we have this discussion we need at least people to report any problems they have with the git integration , real problems not theoretical problems so as a community we can coordinate effort. There is no reason to speculate about the future of Pharo with git since the integration is in a very early stage and we have still a long way to go . I am following the discussion with great interest. What fascinates me about git is that is made around the idea of modular community. Its architecture makes it flexible to send code around and create a community of commits that bounce without a need for centralisation. You could say that each pull request is a message and I feel that git architecture could fit like a glove for Pharo because they speak the same language. Obviously there is still a long road ahead of us but I am excited and believe that slowly people will contribute and in the future we will look back and wonder what tooks us so long to embrace git :D
Le 2/12/14 21:02, kilon alios a écrit :
I think its great that we have this discussion we need at least people to report any problems they have with the git integration , real problems not theoretical problems so as a community we can coordinate effort. There is no reason to speculate about the future of Pharo with git since the integration is in a very early stage and we have still a long way to go . I am following the discussion with great interest.
What fascinates me about git is that is made around the idea of modular community. Its architecture makes it flexible to send code around and create a community of commits that bounce without a need for centralisation. You could say that each pull request is a message and I feel that git architecture could fit like a glove for Pharo because they speak the same language.
Monticello is like that too. A decentralized version management system
Obviously there is still a long road ahead of us but I am excited and believe that slowly people will contribute and in the future we will look back and wonder what tooks us so long to embrace git :D
On Wed, Dec 3, 2014 at 8:21 AM, stepharo <stepharo@free.fr> wrote:
Le 2/12/14 21:02, kilon alios a écrit :
I think its great that we have this discussion we need at least people to report any problems they have with the git integration , real problems not theoretical problems so as a community we can coordinate effort. There is no reason to speculate about the future of Pharo with git since the integration is in a very early stage and we have still a long way to go . I am following the discussion with great interest.
What fascinates me about git is that is made around the idea of modular community. Its architecture makes it flexible to send code around and create a community of commits that bounce without a need for centralisation. You could say that each pull request is a message and I feel that git architecture could fit like a glove for Pharo because they speak the same language.
Monticello is like that too. A decentralized version management system
As is Fossil, another cool tool deserving more success. Phil
Obviously there is still a long road ahead of us but I am excited and believe that slowly people will contribute and in the future we will look back and wonder what tooks us so long to embrace git :D
On 03 Dec 2014, at 08:21, stepharo <stepharo@free.fr> wrote:
Le 2/12/14 21:02, kilon alios a écrit :
I think its great that we have this discussion we need at least people to report any problems they have with the git integration , real problems not theoretical problems so as a community we can coordinate effort. There is no reason to speculate about the future of Pharo with git since the integration is in a very early stage and we have still a long way to go . I am following the discussion with great interest.
What fascinates me about git is that is made around the idea of modular community. Its architecture makes it flexible to send code around and create a community of commits that bounce without a need for centralisation. You could say that each pull request is a message and I feel that git architecture could fit like a glove for Pharo because they speak the same language.
Monticello is like that too. A decentralized version management system
yes, but is a decentralised management system in a way that does not scales in team work (not a problem of monticello, all cms of the time had same problem). They are ok with centralised ways of work (even if decentralised systems): all responsibility is in contributor, so you end having to centralise access rights (this is ok for lots of people, but welll⦠not in open source models that wants to grow from âjust some contributorsâ). The real advantage of git is the model it allows: you have a repository that everybody can fork and when ready, they can do a pull request⦠then responsible can choose to merge or not, or cherry pick, or whatever. In summary: is a lot more dynamic and allows a lot more people contribution. monticello is cool, but is not good for that. and if we put also in the table that we need to spend a lot of time improving *external tools* (like smalltalkhub) just to have something that is way far from what is âstate of the artâ, then the equation starts to be less and less in our favor. Also, the proposal so far is not to drop what we have, but to adapt it to be able to use what is around⦠would be the best of two worlds if you want (even if I believe at the end we will converge in just one). Esteban
Obviously there is still a long road ahead of us but I am excited and believe that slowly people will contribute and in the future we will look back and wonder what tooks us so long to embrace git :D
Le 02/12/2014 17:00, Luc Fabresse a écrit :
Hi,
I continue the discussion here because I really would like to know the cons of using Git + Pharo. From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:
- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?
ConfigurationOfAltBrowser, ConfigurationOfSmaCC show how to load directly from a GitHub repository (or, in the case of SmaCC, load some versions from smalltalkhub, other from github, depending on the version you choose). But the best is the BaselineOf as explained by Dale, especially given that it can works with git tags (and github:// urls). gitfiletree:// urls are designed for development and to couple you with the github repository.
- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?
Yes. Part of it has been automated via gitfiletree, but more should be done to automate. Still, it is reasonable to assume that you'll need access to git command line in real life, and integrating it as an embedded shell inside Smalltalk is a very nice way of handling it.
- Merging could be harder because it would rely on git tools?
Not really if you use the merge driver. For a large merge, git-based tools are a lot faster than Monticello, except for the merge driver which slows done the process a bit (it's written in Pharo, Pharo startup time is significant, and it is called often by git during a merge).
- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo
Yes, you should be ready to pull (or pull often). But pull does a merge, so you have to know what you're doing: conflicts may appear on a pull. In a well organized multi-developper project, you'll work on a personal branch and conflicts won't happen. But git is designed in such a way that a git user can easily shot himself in the foot and create conflicts for his co-workers. git rebase is a good example of how to do that.
Thx for enlightening me,
#Luc
You're welcome, Thierry
participants (14)
-
Andreas Wacknitz -
Ben Coman -
Dale Henrichs -
Eliot Miranda -
Esteban Lorenzano -
kilon alios -
Luc Fabresse -
Max Leske -
Norbert Hartl -
phil＠highoctane.be -
stepharo -
Thierry Goubier -
Tudor Girba -
Yuriy Tymchuk