Video Tutorial - Github for Pharo using Sourcetree
Hello pharoers , at last , my video tutorial for those that are not familiar with git and github, has been uploaded to YouTube. I describe the very basics of the process and give you enough information to create a github repository, clone the online repository to your hard driver and use the hard drive copy to commit changes to your code, upload and download your commits to and from your github repo . I use sourcetree to make the interaction with git as gui based as you are used with Pharo. The tutorial can be watched here https://www.youtube.com/watch?v=n2WNYDtO0cE and these are the relevant links for whatever is used in the tutorial Git http://git-scm.com GitHub https://github.com/ Sourcetree http://www.sourcetreeapp.com SmartGit http://www.syntevo.com/smartgit if you have any issue , problem and compliant, dont be shy, share it :)
thanks I added it to pharo weekly http://pharoweekly.wordpress.com/2014/11/29/github-for-pharo-using-sourcetre... Le 27/11/14 21:46, kilon alios a écrit :
Hello pharoers , at last , my video tutorial for those that are not familiar with git and github, has been uploaded to YouTube. I describe the very basics of the process and give you enough information to create a github repository, clone the online repository to your hard driver and use the hard drive copy to commit changes to your code, upload and download your commits to and from your github repo . I use sourcetree to make the interaction with git as gui based as you are used with Pharo.
The tutorial can be watched here
https://www.youtube.com/watch?v=n2WNYDtO0cE
and these are the relevant links for whatever is used in the tutorial
GitHub https://github.com/
Sourcetree http://www.sourcetreeapp.com
SmartGit http://www.syntevo.com/smartgit
if you have any issue , problem and compliant, dont be shy, share it :)
my pleasure , I am considering also creating a tutorial for fork, branch, merge, merge conflicts, diffs and pull request which are a bit more deep git stuff. I will try to finish it this weekend. On Sat, Nov 29, 2014 at 9:46 AM, stepharo <stepharo@free.fr> wrote:
thanks I added it to pharo weekly
http://pharoweekly.wordpress.com/2014/11/29/github-for- pharo-using-sourcetree-video-by-kilon-alios/
Le 27/11/14 21:46, kilon alios a écrit :
Hello pharoers , at last , my video tutorial for those that are not
familiar with git and github, has been uploaded to YouTube. I describe the very basics of the process and give you enough information to create a github repository, clone the online repository to your hard driver and use the hard drive copy to commit changes to your code, upload and download your commits to and from your github repo . I use sourcetree to make the interaction with git as gui based as you are used with Pharo.
The tutorial can be watched here
https://www.youtube.com/watch?v=n2WNYDtO0cE
and these are the relevant links for whatever is used in the tutorial
GitHub https://github.com/
Sourcetree http://www.sourcetreeapp.com
SmartGit http://www.syntevo.com/smartgit
if you have any issue , problem and compliant, dont be shy, share it :)
Le 29/11/2014 09:16, kilon alios a écrit :
my pleasure , I am considering also creating a tutorial for fork, branch, merge, merge conflicts, diffs and pull request which are a bit more deep git stuff. I will try to finish it this weekend.
Great! I didn't finish the Git chapter on that :( Took me too long to setup the sample repositories for reproducable results... Can you include the GitFileTree-MergeDriver use in there? Git merge conflicts are interesting, but it's good to know we can avoid having them (or at least some of them) in the first place ;) Thierry
On Sat, Nov 29, 2014 at 9:46 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
thanks I added it to pharo weekly
http://pharoweekly.wordpress.__com/2014/11/29/github-for-__pharo-using-sourc... <http://pharoweekly.wordpress.com/2014/11/29/github-for-pharo-using-sourcetre...>
Le 27/11/14 21:46, kilon alios a écrit :
Hello pharoers , at last , my video tutorial for those that are not familiar with git and github, has been uploaded to YouTube. I describe the very basics of the process and give you enough information to create a github repository, clone the online repository to your hard driver and use the hard drive copy to commit changes to your code, upload and download your commits to and from your github repo . I use sourcetree to make the interaction with git as gui based as you are used with Pharo.
The tutorial can be watched here
https://www.youtube.com/watch?__v=n2WNYDtO0cE <https://www.youtube.com/watch?v=n2WNYDtO0cE>
and these are the relevant links for whatever is used in the tutorial
GitHub https://github.com/
Sourcetree http://www.sourcetreeapp.com
SmartGit http://www.syntevo.com/__smartgit <http://www.syntevo.com/smartgit>
if you have any issue , problem and compliant, dont be shy, share it :)
I took a look at gifiletree-Merge drive and from the installation instructions alone , it blew my mind. Is there a simpler way of doing this ? Because I will have to do a separate video tutorial on command line and then another one for git configuration and customisation, I dont see how to do this in a noob friendly manner. I would prefer something that installs from inside Pharo with no use of the terminal. I assume my viewers are new to coding and new to Pharo. Also to create a video tutorial about something I will have first to test and try it for a considerable amount of time so I make sure that I don't introduce viewers to all sort of problems. A side note why I do not use gitfiletree is because I believe that is certainly a convenient tool to use but I will still rely on the external gui to visualise my commits and do things that are outside the scope of gitfiletree , so yes its a bit more tedious for simple tasks but way more efficient for more complex ones. I dont exclude though the possibility one day to come back to pharo even for my git tasks if the tools get sophisticated enough, Pharo definitely has this potential. But for now I would like to continue to explain what cool stuff one can do with sourcetree because its a really awesome git client. On Sat, Nov 29, 2014 at 10:22 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
Le 29/11/2014 09:16, kilon alios a écrit :
my pleasure , I am considering also creating a tutorial for fork, branch, merge, merge conflicts, diffs and pull request which are a bit more deep git stuff. I will try to finish it this weekend.
Great! I didn't finish the Git chapter on that :( Took me too long to setup the sample repositories for reproducable results...
Can you include the GitFileTree-MergeDriver use in there? Git merge conflicts are interesting, but it's good to know we can avoid having them (or at least some of them) in the first place ;)
Thierry
On Sat, Nov 29, 2014 at 9:46 AM, stepharo <stepharo@free.fr
<mailto:stepharo@free.fr>> wrote:
thanks I added it to pharo weekly
http://pharoweekly.wordpress.__com/2014/11/29/github-for-__ pharo-using-sourcetree-video-__by-kilon-alios/ <http://pharoweekly.wordpress.com/2014/11/29/github-for- pharo-using-sourcetree-video-by-kilon-alios/>
Le 27/11/14 21:46, kilon alios a écrit :
Hello pharoers , at last , my video tutorial for those that are not familiar with git and github, has been uploaded to YouTube. I describe the very basics of the process and give you enough information to create a github repository, clone the online repository to your hard driver and use the hard drive copy to commit changes to your code, upload and download your commits to and from your github repo . I use sourcetree to make the interaction with git as gui based as you are used with Pharo.
The tutorial can be watched here
https://www.youtube.com/watch?__v=n2WNYDtO0cE <https://www.youtube.com/watch?v=n2WNYDtO0cE>
and these are the relevant links for whatever is used in the tutorial
GitHub https://github.com/
Sourcetree http://www.sourcetreeapp.com
SmartGit http://www.syntevo.com/__smartgit <http://www.syntevo.com/ smartgit>
if you have any issue , problem and compliant, dont be shy, share it :)
Le 29/11/2014 11:34, kilon alios a écrit :
I took a look at gifiletree-Merge drive and from the installation instructions alone , it blew my mind. Is there a simpler way of doing this ? Because I will have to do a separate video tutorial on command line and then another one for git configuration and customisation, I dont see how to do this in a noob friendly manner. I would prefer something that installs from inside Pharo with no use of the terminal. I assume my viewers are new to coding and new to Pharo. Also to create a video tutorial about something I will have first to test and try it for a considerable amount of time so I make sure that I don't introduce viewers to all sort of problems.
Yes, this is that "amount of time" stuff where I stopped in the Git chapter. And, yes, the merge driver is fairly low level (but it would not be that hard to add the setup of the merge driver when cloning a repository with, say, GitFileTree).
A side note why I do not use gitfiletree is because I believe that is certainly a convenient tool to use but I will still rely on the external gui to visualise my commits and do things that are outside the scope of gitfiletree , so yes its a bit more tedious for simple tasks but way more efficient for more complex ones. I dont exclude though the possibility one day to come back to pharo even for my git tasks if the tools get sophisticated enough, Pharo definitely has this potential.
One of the thing we need to look at is use cases with git and Pharo. GitFileTree is/was an attempt at going as simple as possible on the 'how to do it' so that we could concentrate on doing usefull things with it ('now that we have it, what can we do around it?'). As I'm the only one projecting his use case around it, it doesn't see much progress on that front. It suits me and people with the same workflow (and knowing that it does exactly what you would do in most cases on the command line is one of the features: not a fault). For a true 'doing something with it', you have to look into what Dale Henrichs has done with tODE. He is, as far as I could read, a long way up front us.
But for now I would like to continue to explain what cool stuff one can do with sourcetree because its a really awesome git client.
And challenging the Pharo community with it ;) Thierry
I wonder how we could use tODE for remote Pharo dev too. The way Dale shows things is really compelling indeed. Phil Le 29 nov. 2014 11:54, "Thierry Goubier" <thierry.goubier@gmail.com> a écrit :
Le 29/11/2014 11:34, kilon alios a écrit :
I took a look at gifiletree-Merge drive and from the installation instructions alone , it blew my mind. Is there a simpler way of doing this ? Because I will have to do a separate video tutorial on command line and then another one for git configuration and customisation, I dont see how to do this in a noob friendly manner. I would prefer something that installs from inside Pharo with no use of the terminal. I assume my viewers are new to coding and new to Pharo. Also to create a video tutorial about something I will have first to test and try it for a considerable amount of time so I make sure that I don't introduce viewers to all sort of problems.
Yes, this is that "amount of time" stuff where I stopped in the Git chapter. And, yes, the merge driver is fairly low level (but it would not be that hard to add the setup of the merge driver when cloning a repository with, say, GitFileTree).
A side note why I do not use gitfiletree is because I believe that is
certainly a convenient tool to use but I will still rely on the external gui to visualise my commits and do things that are outside the scope of gitfiletree , so yes its a bit more tedious for simple tasks but way more efficient for more complex ones. I dont exclude though the possibility one day to come back to pharo even for my git tasks if the tools get sophisticated enough, Pharo definitely has this potential.
One of the thing we need to look at is use cases with git and Pharo.
GitFileTree is/was an attempt at going as simple as possible on the 'how to do it' so that we could concentrate on doing usefull things with it ('now that we have it, what can we do around it?').
As I'm the only one projecting his use case around it, it doesn't see much progress on that front. It suits me and people with the same workflow (and knowing that it does exactly what you would do in most cases on the command line is one of the features: not a fault).
For a true 'doing something with it', you have to look into what Dale Henrichs has done with tODE. He is, as far as I could read, a long way up front us.
But for now I would like to continue to explain what cool stuff one can
do with sourcetree because its a really awesome git client.
And challenging the Pharo community with it ;)
Thierry
"For a true 'doing something with it', you have to look into what Dale Henrichs has done with tODE. He is, as far as I could read, a long way up front us." no idea what tODE is doing, I have seen some demos but I have not understand it. "Filetree metadata is a pain in the ass when merging and Thierry's tool solves that." yeah I have seen that he mention that json is binary file .... this is weird choice why choose a binary file for version controlling . I thought json file are text files. "Also realize that SourceTree is not available in Linux. " have you watched my video tutorial ? I already provide a very good solution for that too :) anyway I am new to all this but not new to git , though I have to confess I have done like one pull request and very few merges, so I will postpone the tutorials for now for when I feel more comfortable with using the tools .
Le 29/11/2014 13:15, kilon alios a écrit :
"For a true 'doing something with it', you have to look into what Dale Henrichs has done with tODE. He is, as far as I could read, a long way up front us."
no idea what tODE is doing, I have seen some demos but I have not understand it.
What I know is that Dale has brought together everything git and smalltalk need: - The merge driver, - a Meld equivalent, - a Project idea (saving multiple packages as a single commit) - Filetree and git. I haven't checked how he has done that in the detail; we just know this was what was needed (and if there is an effort in that direction, I'll know where to get the pieces).
"Filetree metadata is a pain in the ass when merging and Thierry's tool solves that."
yeah I have seen that he mention that json is binary file .... this is weird choice why choose a binary file for version controlling . I thought json file are text files.
You have both: you have a text file containing the version information (and ancestry), and you have properties in Json files (class definitions, method timestamps). This is usual and listed in the git documentation (or any VCS). Git decides whether a file is text-based or binary and uses different diff and merge strategies accordingly. Text based git strategies only work if changes in the files can be resumed by adding or removing lines. a) If your text file is a single line -> doesn't work -> conflict b) If your changes occur over a single line -> probable conflict when merging c) If your text file contains a complex tree structure -> adding/removing lines doesn't work. Version metadata is a), b) and c). Json is a) and b) in FileTree case.
"Also realize that SourceTree is not available in Linux. "
have you watched my video tutorial ? I already provide a very good solution for that too :)
anyway I am new to all this but not new to git , though I have to confess I have done like one pull request and very few merges, so I will postpone the tutorials for now for when I feel more comfortable with using the tools .
I recently did a merge between the pharo3.0 and the pharo4.0 branches of AltBrowser; if you are interested, you can have a look and try to reproduce it (by doing a checkout of the pharo4.0 branch to the commit id just before the merge and merging with pharo3.0 again. Doing it with and without the merge driver could be interesting). Keeping in sync your clone of AltBrowser with the fixes I push could be a nice example as well. Thierry
I recently did a merge between the pharo3.0 and the pharo4.0 branches of AltBrowser; if you are interested, you can have a look and try to reproduce it (by doing a checkout of the pharo4.0 branch to the commit id just before the merge and merging with pharo3.0 again. Doing it with and without the merge driver could be interesting).
Keeping in sync your clone of AltBrowser with the fixes I push could be a nice example as well.
Thierry
yeah more the reason to practice my merge skills. I had not the time to play with your browser yet, but I will and I am sure I will deal with these merge issues. Obviously if the merge driver is so needed makes sense to add it to a video tutorial but I will still like to streamline its installation to something easier, maybe I could help there if you dont beat me to the task first. In any case I am very interested into contributing to improving the workflow between Pharo and Git.
Kilon, As Thierry points out I think that it is important to have project orientation where: project == baseline == git repo In the attached screenshot (tode_project_list) you see a project browser from tode, where each project loaded in the image is managed. There are git-based/baseline projects (filetree and github repos) and mcz/configuration based repos (http repos). For git repos, it is important to know the SHA of the commit that is loaded into your image and the name of the branch that you have checked out (the middle column). The main menu represents the "standard" operations that can be performed for a project. With the exception of the `push` command, all of the operations can be performed against a git or mcz repository. For example the `log` command for a git repo shows the commit log while the log for an mcz repo shows the commit history of the configuration project. The `changes` command compares all packages for a project against the disk version of the packages. The `save` command saves all of the dirty packages to the repo and for git repos does a git commit ... and so on. The Git menu has get-specific commands for doing fairly common git operations. tODE has it's own command line application (from within the image) and the full range of git commands can be run in the "tODE shell" (callable from Smalltalk) so that uncommon operations can be run from within the image ... tODE also allows you to write your scripts (in Smalltalk) so it is easy to write your own custom operations that mix and match git operations and Metacello (for example)... The importance of tracking the loaded commit SHA is illustrated by the second screen shot (tode_project_list_conflicts). The projects highlighted in red, indicate that the SHA of the git repo on disk is different than the SHA of the commit loaded into the image (a very common occurrence when working with multiple images that share git repos). On the main menu you see that the two menu items: `skew diff` and `skew save` are enabled. `skew diff` gives you a view of the differences between the two commits (git diffs can include non-smalltalk diffs) so that you can determine what has changed .... `skew save` is important if you have image-level changes that need to be merged with into the new git SHA ... `skew save` walks you through the steps of: 1. checkout out original SHA 2. create a new branch 3. save changes to the new branch 4. merge the new branch into the original branch The important take-away from this is that when working with git and Smalltalk you must track the SHA that has been loaded into the image (the latest version of Metacello tracks this information in the project registry) and you must have in-image tool support for recognizing SHA skew. It's not absolutely necessary to provide a tool for `skew save`, but it _is_ tedious to "merge your way out of trouble" manually and in-image tools make this situation much more tolerable ... Dale On Sat, Nov 29, 2014 at 4:15 AM, kilon alios <kilon.alios@gmail.com> wrote:
"For a true 'doing something with it', you have to look into what Dale Henrichs has done with tODE. He is, as far as I could read, a long way up front us."
no idea what tODE is doing, I have seen some demos but I have not understand it.
"Filetree metadata is a pain in the ass when merging and Thierry's tool solves that."
yeah I have seen that he mention that json is binary file .... this is weird choice why choose a binary file for version controlling . I thought json file are text files.
"Also realize that SourceTree is not available in Linux. "
have you watched my video tutorial ? I already provide a very good solution for that too :)
anyway I am new to all this but not new to git , though I have to confess I have done like one pull request and very few merges, so I will postpone the tutorials for now for when I feel more comfortable with using the tools .
"The important take-away from this is that when working with git and Smalltalk you must track the SHA that has been loaded into the image (the latest version of Metacello tracks this information in the project registry) and you must have in-image tool support for recognizing SHA skew. It's not absolutely necessary to provide a tool for `skew save`, but it _is_ tedious to "merge your way out of trouble" manually and in-image tools make this situation much more tolerable ..." well I have to confess all this is way out of my league :D As I said before I have done some merges with git, but nothing so complex to require knowing all this stuff. But then I work mostly on my own small projects and not in large teams.
On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios@gmail.com> wrote:
"The important take-away from this is that when working with git and Smalltalk you must track the SHA that has been loaded into the image (the latest version of Metacello tracks this information in the project registry) and you must have in-image tool support for recognizing SHA skew. It's not absolutely necessary to provide a tool for `skew save`, but it _is_ tedious to "merge your way out of trouble" manually and in-image tools make this situation much more tolerable ..."
well I have to confess all this is way out of my league :D
Haha ... and that's the point ... with tool support you don't have to be "in that league":)
As I said before I have done some merges with git, but nothing so complex to require knowing all this stuff. But then I work mostly on my own small projects and not in large teams.
FWIW, I was getting myself into this trouble, by working in multiple images that were distributed over time ... I would come back to an older image and discover that I'd updated one of my shared projects and I had modifications to that project that I wanted to save ... Tools are supposed to help people who do not have a PHD in git and not get in the way of those who do:) Dale
I dont disagree but when it comes to me making a tutorial about something then foremost I want to know exactly what I am talking about. So its pointless for me to talk about merges using filetree and gitfiletree unless I understand these specific topic inside out. I dont have a problem getting a phd, I am a bookworm by nature anyway and I love learning. I am not saying also that tools are not needed to make things easier, obviously if tools make life easier then I am all for using them. But I need to make sure first that the tools you guys make work well in practice to recommend them to my viewers. Thats how serious teaching works. So I think for now would be better if I get more experience with merges as Thierry said and study more the internals of git. So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files. On Sun, Nov 30, 2014 at 5:20 PM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios@gmail.com> wrote:
"The important take-away from this is that when working with git and Smalltalk you must track the SHA that has been loaded into the image (the latest version of Metacello tracks this information in the project registry) and you must have in-image tool support for recognizing SHA skew. It's not absolutely necessary to provide a tool for `skew save`, but it _is_ tedious to "merge your way out of trouble" manually and in-image tools make this situation much more tolerable ..."
well I have to confess all this is way out of my league :D
Haha ... and that's the point ... with tool support you don't have to be "in that league":)
As I said before I have done some merges with git, but nothing so complex to require knowing all this stuff. But then I work mostly on my own small projects and not in large teams.
FWIW, I was getting myself into this trouble, by working in multiple images that were distributed over time ... I would come back to an older image and discover that I'd updated one of my shared projects and I had modifications to that project that I wanted to save ...
Tools are supposed to help people who do not have a PHD in git and not get in the way of those who do:)
Dale
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios@gmail.com> wrote:
So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files.
Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ... The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history. When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too. I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ... As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ... Dale
ok Dale thanks for the explanation it makes things much clearer right now. I am glad it works well for you that means it will work well for me too and thus I am now much less reluctant to recommend it. Will give it a try and make a nice tutorial about it , together with gitfiletree. On Sun, Nov 30, 2014 at 6:14 PM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios@gmail.com> wrote:
So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files.
Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ...
The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history.
When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too.
I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ...
As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ...
Dale
Hi Dale, On Nov 30, 2014, at 8:14 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios@gmail.com> wrote:
So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files.
Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ...
The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history.
When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too.
I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ...
As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ...
Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello?
Dale
Eliot, If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ... `adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ... My statement about "as the community begins to use git-based repos as their primary repository" includes a broad definition of community, in my mind:) Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ... So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?) Dale On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Dale,
On Nov 30, 2014, at 8:14 AM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios@gmail.com> wrote:
So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files.
Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ...
The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history.
When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too.
I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ...
As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ...
Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello?
Dale
Hi Dale, On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Eliot,
If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ...
`adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ...
So *please* continue to be stubborn :-) My statement about "as the community begins to use git-based repos as their
primary repository" includes a broad definition of community, in my mind:)
+1 Cross-platform package portability has always been one of my primary
concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ...
So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?)
Which would be reasonable, but it needs to be there. And thanks. Dale
On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Dale,
On Nov 30, 2014, at 8:14 AM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios@gmail.com> wrote:
So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files.
Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ...
The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history.
When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too.
I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ...
As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ...
Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello?
Dale
-- best, Eliot
On 01 Dec 2014, at 19:11, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Dale,
On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: Eliot,
If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ...
`adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ...
So *please* continue to be stubborn :-)
but this is a limitation of gitfiletree. real git integration (using libgit2) should be perfectly capable of reconstruct history without any metadata. also, in a point (not now, but eventually)⦠we will need to drop something. The idea of keeping anything ad eternum just does not scales. Esteban
My statement about "as the community begins to use git-based repos as their primary repository" includes a broad definition of community, in my mind:)
+1
Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ...
So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?)
exactly.
Which would be reasonable, but it needs to be there. And thanks.
Dale
On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote: Hi Dale,
On Nov 30, 2014, at 8:14 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote: So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files.
Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ...
The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history.
When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too.
I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ...
As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ...
Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello?
Dale
-- best, Eliot
Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
On 01 Dec 2014, at 19:11, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi Dale,
On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
Eliot,
If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ...
`adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ...
So *please* continue to be stubborn :-)
but this is a limitation of gitfiletree.
This is a limitation of FileTree, not GitFileTree.
real git integration (using libgit2) should be perfectly capable of reconstruct history without any metadata.
As GitFileTree has been doing without libgit2 for, how long already?
also, in a point (not now, but eventually)⦠we will need to drop something. The idea of keeping anything ad eternum just does not scales.
But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. Thierry
Esteban
My statement about "as the community begins to use git-based repos as their primary repository" includes a broad definition of community, in my mind:)
+1
Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ...
So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?)
exactly.
Which would be reasonable, but it needs to be there. And thanks.
Dale
On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi Dale,
On Nov 30, 2014, at 8:14 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:
So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files.
Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ...
The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history.
When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too.
I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ...
As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ...
Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello?
Dale
-- best, Eliot
On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
also, in a point (not now, but eventually)⦠we will need to drop something. The idea of keeping anything ad eternum just does not scales.
But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well.
Thierry, Not sure if you are being sarcastic here:) I just don't see how the current FileTree format "delays git integration in the Pharo platform." I consider git integrated into tODE and tODE uses FileTree. Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the "system browser" so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files... A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages]. FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser. So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system. Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ... Dale [1] https://github.com/rjsargent/CypressReferenceImplementation
On 01 Dec 2014, at 20:25, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote: Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
also, in a point (not now, but eventually)⦠we will need to drop something. The idea of keeping anything ad eternum just does not scales.
But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well.
Thierry,
Not sure if you are being sarcastic here:)
he was, donât worry :) and as an aswer: yes, Iâm not happy with filetree format, but I wouldnât spend changing it until we have ready other parts of the tooling I think is necessary (using libgit2 instead osprocess for me is a must, while changing filetree format is just an enhancement) but⦠in the not so far future the metadata *needs* to change, Iâm sorry. Merging in complex project (more than one developer, in fact) can become a pain if we do not improve that⦠even with mergetools from Thierry, is too complicated). Esteban
I just don't see how the current FileTree format "delays git integration in the Pharo platform."
I consider git integrated into tODE and tODE uses FileTree.
Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the "system browser" so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files...
A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages].
FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser.
So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system.
Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ...
Dale
[1] https://github.com/rjsargent/CypressReferenceImplementation <https://github.com/rjsargent/CypressReferenceImplementation>
Le 01/12/2014 21:04, Esteban Lorenzano a écrit :
On 01 Dec 2014, at 20:25, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
also, in a point (not now, but eventually)⦠we will need to drop something. The idea of keeping anything ad eternum just does not scales.
But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well.
Thierry,
Not sure if you are being sarcastic here:)
he was, donât worry :)
Maybe I was :)
and as an aswer: yes, Iâm not happy with filetree format, but I wouldnât spend changing it until we have ready other parts of the tooling I think is necessary (using libgit2 instead osprocess for me is a must, while changing filetree format is just an enhancement)
When I considered libgit2 a while ago, I was like you: a must. Then I saw that: libgit2 was low-level => lot's of code in Pharo do do simple, basic stuff. libgit2 required changes in NativeBoost => what, NativeBoost isn't ready? Pharo is stuck in 32bits land=>No libgit2 by default on target OS. NativeBoost is x86 only? No libgit2 on ARM. In short: I don't have the resources to do that. It's too expensive for the benefits. I'm impressed by Max and your dedication.
but⦠in the not so far future the metadata *needs* to change, Iâm sorry. Merging in complex project (more than one developer, in fact) can become a pain if we do not improve that⦠even with mergetools from Thierry, is too complicated).
The way you say it, I wonder if you understand what the MergeDriver is supposed to solve (and what it isn't). You'll have to say more ;) (especially the bit about the merge of large projects/multiple developers being too complicated...) Thierry
Esteban
On 01 Dec 2014, at 21:48, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 01/12/2014 21:04, Esteban Lorenzano a écrit :
On 01 Dec 2014, at 20:25, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
also, in a point (not now, but eventually)⦠we will need to drop something. The idea of keeping anything ad eternum just does not scales.
But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well.
Thierry,
Not sure if you are being sarcastic here:)
he was, donât worry :)
Maybe I was :)
and as an aswer: yes, Iâm not happy with filetree format, but I wouldnât spend changing it until we have ready other parts of the tooling I think is necessary (using libgit2 instead osprocess for me is a must, while changing filetree format is just an enhancement)
When I considered libgit2 a while ago, I was like you: a must. Then I saw that: libgit2 was low-level => lot's of code in Pharo do do simple, basic stuff. libgit2 required changes in NativeBoost => what, NativeBoost isn't ready? Pharo is stuck in 32bits land=>No libgit2 by default on target OS. NativeBoost is x86 only? No libgit2 on ARM.
Iâm also concerned about that (32bits only). But we are already working on a solution. (and libgit2 support is already there, thanks to Max). as I said⦠our problem (not yours, but ours) is that we need to keep pharo independent of installed tools. So⦠libgit2. Otherwise I would be pushing gitfiletree a lot more loud :) Esteban
In short: I don't have the resources to do that. It's too expensive for the benefits. I'm impressed by Max and your dedication.
but⦠in the not so far future the metadata *needs* to change, Iâm sorry. Merging in complex project (more than one developer, in fact) can become a pain if we do not improve that⦠even with mergetools from Thierry, is too complicated).
The way you say it, I wonder if you understand what the MergeDriver is supposed to solve (and what it isn't). You'll have to say more ;)
(especially the bit about the merge of large projects/multiple developers being too complicated...)
Thierry
Esteban
Le 01/12/2014 21:53, Esteban Lorenzano a écrit :
Iâm also concerned about that (32bits only). But we are already working on a solution. (and libgit2 support is already there, thanks to Max). as I said⦠our problem (not yours, but ours) is that we need to keep pharo independent of installed tools. So⦠libgit2. Otherwise I would be pushing gitfiletree a lot more loud :)
Yes. This is a strong point. I considered bundling a git along, to solve issues like Stephan's. Bundling libgit2 is a bit similar, in a way. Mind you. I do prefer the libgit2 + NativeBoost... but it was far too costly. And still not that portable (i.e. no git on the RaspberryPi, for example). And some of my internal arguments for libgit2 (being able to correctly propagate a Monticello merge into git) were wrong, but it took me time and the MergeDriver to understand why. Thierry
Le 01/12/2014 20:25, Dale Henrichs a écrit :
On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
also, in a point (not now, but eventually)⦠we will need to drop something. The idea of keeping anything ad eternum just does not scales.
But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well.
Thierry,
Not sure if you are being sarcastic here:)
I wish I was :(
I just don't see how the current FileTree format "delays git integration in the Pharo platform."
This is exactly my point. It works, it is cross-platform (mcz to FileTree and back), it has a significant bug squashing done, it's stable. Yes, it's not perfect. Metadata is noisy in github output, it used to cause problem when merging, and there is issues with very long path and file names. However, all discussions about changing the file format around Pharo brings no convincing arguments... just cosmetic changes, which basically says: lets do the same as before, but not compatible and with a new code base so that we can have our own new bugs. (If I had to redesign the file format for git use, I'd consider FileOut with a better parser, and alphabetical ordering: minimal code for reading and writing. But I'd loose some of the features that tODE has when querying the git logs).
I consider git integrated into tODE and tODE uses FileTree.
Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the "system browser" so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files...
I agree. But you are at the point where you just say: "libgit2 or GitFileTree are just means to an end: better tools to tap in the power of git and do something interesting with it." Look the situation of Pharo... They are still trying to get the infrastructure working. Yes, libgit2 will be better than GitFileTree, but barely, and how many years will Pharo have invested for that? In the mean time, what should I invest in? A GitFileTree which will be wasted anyway? And in a few years time, will NativeBoost still be in use? Or replaced by FFI and LowCode? With libgit2 reimplemented? With no support of libgit2 on ARM? And for what? The goal is to hide git behind any package and source management tools we have in the image, after all.
A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages].
FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser.
So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system.
Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ...
Yes, this is it: that focus is interesting. That's why I refer to tODE when I say you are showing us the way on git. But Pharo is a long way from being that ambitious. Thierry
On 01 Dec 2014, at 21:15, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 01/12/2014 20:25, Dale Henrichs a écrit :
On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
also, in a point (not now, but eventually)⦠we will need to drop something. The idea of keeping anything ad eternum just does not scales.
But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well.
Thierry,
Not sure if you are being sarcastic here:)
I wish I was :(
I just don't see how the current FileTree format "delays git integration in the Pharo platform."
This is exactly my point. It works, it is cross-platform (mcz to FileTree and back), it has a significant bug squashing done, it's stable.
Yes, it's not perfect. Metadata is noisy in github output, it used to cause problem when merging, and there is issues with very long path and file names.
However, all discussions about changing the file format around Pharo brings no convincing arguments... just cosmetic changes, which basically says: lets do the same as before, but not compatible and with a new code base so that we can have our own new bugs.
(If I had to redesign the file format for git use, I'd consider FileOut with a better parser, and alphabetical ordering: minimal code for reading and writing. But I'd loose some of the features that tODE has when querying the git logs).
I consider git integrated into tODE and tODE uses FileTree.
Perhaps it's a matter of approach. In tODE the git support is NOT centered on the package browser ... the git support is built into the "system browser" so you can look at git history from a class, method OR package perspective ... Other perspectives are possible as it is relatively straightforward to pull up the git history of any directory or file ... and git integration should include the ability to view diffs and merge non-smalltalk files...
I agree. But you are at the point where you just say:
"libgit2 or GitFileTree are just means to an end: better tools to tap in the power of git and do something interesting with it."
Look the situation of Pharo... They are still trying to get the infrastructure working. Yes, libgit2 will be better than GitFileTree, but barely, and how many years will Pharo have invested for that? In the mean time, what should I invest in? A GitFileTree which will be wasted anyway? And in a few years time, will NativeBoost still be in use? Or replaced by FFI and LowCode? With libgit2 reimplemented? With no support of libgit2 on ARM?
And for what? The goal is to hide git behind any package and source management tools we have in the image, after all.
well, no. the goal is to not needing to install git command line to use it (is a requirement: pharo needs to keep being as portable and independent as always) :) from my point of view, Iâm quite happy with gitfiletree. I will just intend to make it work without OSProcess. but in other discussions. Yes, we will need to stabilise things in a point. Iâm not happy with general status of⦠well, a lot of things. And not in status of stability (most of them work really well), but Iâm working to try to ensure the maintainability in the long way⦠and that includes time to time needing to admit that we cannot maintain everything (thus my push of (git)filetree and the use of git in general) Esteban
A package is just one of the artifacts that is stored in a git repository. Monticello packages have Monticello characteristics ... Cypress packages without Monticello meta data[1] are another package format and they have slightly different characteristics than Monticello packages and they are equally supported by tODE. [To be fair the Cypress package support is still experimental but a year ago I was doing active development using tODE and Cypress packages in conjunction with Monticello packages].
FileTree intentionally supports Monticello-style packages so that the FileTree packages can leverage the existing Monticello-based tools like Metacello (I had to extend Metacello to support Cypress-based packages) or the Monticello Browser.
So at the end of the day, I think that git integration for Pharo depends upon a broader approach to integrating git-based tools throughout the tool eco-system.
Once you start looking at a chunk of versioned disk as containing more than just Smalltalk source code there a numerous possibilities for building in-image tool support for distributing, sharing and maintaining documentation, workspaces, plugins, deployment scripts, etc. way beyond the limitations of a package ...
Yes, this is it: that focus is interesting. That's why I refer to tODE when I say you are showing us the way on git. But Pharo is a long way from being that ambitious.
Thierry
Le 01/12/2014 21:39, Esteban Lorenzano a écrit :
the goal is to not needing to install git command line to use it (is a requirement: pharo needs to keep being as portable and independent as always) :) from my point of view, Iâm quite happy with gitfiletree. I will just intend to make it work without OSProcess.
I can understand that intent.
but in other discussions. Yes, we will need to stabilise things in a point. Iâm not happy with general status of⦠well, a lot of things. And not in status of stability (most of them work really well), but Iâm working to try to ensure the maintainability in the long way⦠and that includes time to time needing to admit that we cannot maintain everything (thus my push of (git)filetree and the use of git in general)
And I can only thank all the Pharo team for the impressive stability going from Pharo3 to Pharo4. Thierry
Esteban
kilon alios wrote:
I dont disagree but when it comes to me making a tutorial about something then foremost I want to know exactly what I am talking about. So its pointless for me to talk about merges using filetree and gitfiletree unless I understand these specific topic inside out.
I dont have a problem getting a phd, I am a bookworm by nature anyway and I love learning. I am not saying also that tools are not needed to make things easier, obviously if tools make life easier then I am all for using them. But I need to make sure first that the tools you guys make work well in practice to recommend them to my viewers. Thats how serious teaching works. So I think for now would be better if I get more experience with merges as Thierry said and study more the internals of git.
You may have seen this already... http://git-scm.com/book/en/v1/Git-Internals
So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files.
On Sun, Nov 30, 2014 at 5:20 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:
"The important take-away from this is that when working with git and Smalltalk you must track the SHA that has been loaded into the image (the latest version of Metacello tracks this information in the project registry) and you must have in-image tool support for recognizing SHA skew. It's not absolutely necessary to provide a tool for `skew save`, but it _is_ tedious to "merge your way out of trouble" manually and in-image tools make this situation much more tolerable ..."
well I have to confess all this is way out of my league :D
Haha ... and that's the point ... with tool support you don't have to be "in that league":)
As I said before I have done some merges with git, but nothing so complex to require knowing all this stuff. But then I work mostly on my own small projects and not in large teams.
FWIW, I was getting myself into this trouble, by working in multiple images that were distributed over time ... I would come back to an older image and discover that I'd updated one of my shared projects and I had modifications to that project that I wanted to save ...
Tools are supposed to help people who do not have a PHD in git and not get in the way of those who do:)
Dale
yes I am aware of git documentation thus I mention it in my video tutorial On Wed, Dec 3, 2014 at 2:26 PM, Ben Coman <btc@openinworld.com> wrote:
kilon alios wrote:
I dont disagree but when it comes to me making a tutorial about something then foremost I want to know exactly what I am talking about. So its pointless for me to talk about merges using filetree and gitfiletree unless I understand these specific topic inside out. I dont have a problem getting a phd, I am a bookworm by nature anyway and I love learning. I am not saying also that tools are not needed to make things easier, obviously if tools make life easier then I am all for using them. But I need to make sure first that the tools you guys make work well in practice to recommend them to my viewers. Thats how serious teaching works. So I think for now would be better if I get more experience with merges as Thierry said and study more the internals of git.
You may have seen this already... http://git-scm.com/book/en/v1/Git-Internals
So far all I knew that using git for binary files was a no go, doable but
not recommended. Thus I found strange that filetree uses binary files. On Sun, Nov 30, 2014 at 5:20 PM, Dale Henrichs < dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:
On Sun, Nov 30, 2014 at 4:19 AM, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:
"The important take-away from this is that when working with git and Smalltalk you must track the SHA that has been loaded into the image (the latest version of Metacello tracks this information in the project registry) and you must have in-image tool support for recognizing SHA skew. It's not absolutely necessary to provide a tool for `skew save`, but it _is_ tedious to "merge your way out of trouble" manually and in-image tools make this situation much more tolerable ..."
well I have to confess all this is way out of my league :D
Haha ... and that's the point ... with tool support you don't have to be "in that league":)
As I said before I have done some merges with git, but nothing so complex to require knowing all this stuff. But then I work mostly on my own small projects and not in large teams.
FWIW, I was getting myself into this trouble, by working in multiple images that were distributed over time ... I would come back to an older image and discover that I'd updated one of my shared projects and I had modifications to that project that I wanted to save ... Tools are supposed to help people who do not have a PHD in git and not get in the way of those who do:)
Dale
Kilon, The merge driver is needed when you work with several people in a given repo and want to merge branches etc. Filetree metadata is a pain in the ass when merging and Thierry's tool solves that. If you do any complicated thing with branches you'll have to understand git cli tools anyway. Once installed it is transparent. If one is working in its own branch there is no need for it. Also realize that SourceTree is not available in Linux. I have been using git gui and gitk successfully there along with meld for three way merges. Phil Le 29 nov. 2014 11:35, "kilon alios" <kilon.alios@gmail.com> a écrit :
I took a look at gifiletree-Merge drive and from the installation instructions alone , it blew my mind. Is there a simpler way of doing this ? Because I will have to do a separate video tutorial on command line and then another one for git configuration and customisation, I dont see how to do this in a noob friendly manner. I would prefer something that installs from inside Pharo with no use of the terminal. I assume my viewers are new to coding and new to Pharo. Also to create a video tutorial about something I will have first to test and try it for a considerable amount of time so I make sure that I don't introduce viewers to all sort of problems.
A side note why I do not use gitfiletree is because I believe that is certainly a convenient tool to use but I will still rely on the external gui to visualise my commits and do things that are outside the scope of gitfiletree , so yes its a bit more tedious for simple tasks but way more efficient for more complex ones. I dont exclude though the possibility one day to come back to pharo even for my git tasks if the tools get sophisticated enough, Pharo definitely has this potential.
But for now I would like to continue to explain what cool stuff one can do with sourcetree because its a really awesome git client.
On Sat, Nov 29, 2014 at 10:22 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
Le 29/11/2014 09:16, kilon alios a écrit :
my pleasure , I am considering also creating a tutorial for fork, branch, merge, merge conflicts, diffs and pull request which are a bit more deep git stuff. I will try to finish it this weekend.
Great! I didn't finish the Git chapter on that :( Took me too long to setup the sample repositories for reproducable results...
Can you include the GitFileTree-MergeDriver use in there? Git merge conflicts are interesting, but it's good to know we can avoid having them (or at least some of them) in the first place ;)
Thierry
On Sat, Nov 29, 2014 at 9:46 AM, stepharo <stepharo@free.fr
<mailto:stepharo@free.fr>> wrote:
thanks I added it to pharo weekly
http://pharoweekly.wordpress.__com/2014/11/29/github-for-__ pharo-using-sourcetree-video-__by-kilon-alios/ <http://pharoweekly.wordpress.com/2014/11/29/github-for- pharo-using-sourcetree-video-by-kilon-alios/>
Le 27/11/14 21:46, kilon alios a écrit :
Hello pharoers , at last , my video tutorial for those that are not familiar with git and github, has been uploaded to YouTube. I describe the very basics of the process and give you enough information to create a github repository, clone the online repository to your hard driver and use the hard drive copy to commit changes to your code, upload and download your commits to and from your github repo . I use sourcetree to make the interaction with git as gui based as you are used with Pharo.
The tutorial can be watched here
https://www.youtube.com/watch?__v=n2WNYDtO0cE <https://www.youtube.com/watch?v=n2WNYDtO0cE>
and these are the relevant links for whatever is used in the tutorial
GitHub https://github.com/
Sourcetree http://www.sourcetreeapp.com
SmartGit http://www.syntevo.com/__smartgit <http://www.syntevo.com/ smartgit>
if you have any issue , problem and compliant, dont be shy, share it :)
participants (8)
-
Ben Coman -
Dale Henrichs -
Eliot Miranda -
Esteban Lorenzano -
kilon alios -
phil＠highoctane.be -
stepharo -
Thierry Goubier