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 and these are the relevant links for whatever is used in the tutorial Git GitHub Sourcetree 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-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 > > 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 :) |
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 <[hidden email]> wrote: thanks I added it to pharo weekly |
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 <[hidden email] > <mailto:[hidden email]>> 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 > > Git > http://git-scm.com > > 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 <[hidden email]> wrote: Le 29/11/2014 09:16, kilon alios 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 |
In reply to this post by kilon.alios
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" <[hidden email]> a écrit :
|
In reply to this post by Thierry Goubier
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" <[hidden email]> a écrit :
Le 29/11/2014 11:34, 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. "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). 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. |
In reply to this post by kilon.alios
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 <[hidden email]> wrote:
tode_project_list.png (245K) Download Attachment tode_project_list_conflicts.png (194K) Download Attachment |
"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 <[hidden email]> wrote:
Haha ... and that's the point ... with tool support you don't have to be "in that league":)
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 <[hidden email]> wrote:
|
On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <[hidden email]> wrote:
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 <[hidden email]> wrote:
|
In reply to this post by Dale Henrichs-3
Hi 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 <[hidden email]> wrote:
|
Hi Dale,
On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs <[hidden email]> wrote:
So *please* continue to be stubborn :-)
+1
Which would be reasonable, but it needs to be there. And thanks.
best,
Eliot |
Free forum by Nabble | Edit this page |