How to get started with Git and Pharo?

Le 26/06/2014 19:11, Yuriy Tymchuk a écrit :
> I can only suggest you to read my blogpost about configurations and versioning: http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo.html
>
> I usually mix filetree and gitfiletree. Last one is better, because you don’t have to remember to commit in git each time you commit in pharo.
> (Also I think that gitfiletree is not working with Pharo4)

Now it works with Pharo4!

Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

On 27 Jun 2014, at 15:53, Goubier Thierry <[hidden email]> wrote:

>
>
> Le 26/06/2014 19:11, Yuriy Tymchuk a écrit :
>> I can only suggest you to read my blogpost about configurations and versioning: http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo.html
>>
>> I usually mix filetree and gitfiletree. Last one is better, because you don’t have to remember to commit in git each time you commit in pharo.
>> (Also I think that gitfiletree is not working with Pharo4)
>
> Now it works with Pharo4!

Cool. Thanks!

thank dale. I'm using thunderbid and sometimes I have some mails that I do not see and I have to query explicitly. I will read this full thread and the doc.

stef

Stef,

My introduction to git came largely from reading "A successful Git branching model"[1]. I tried to think how to map this particular git work flow to Metacello and long story short, decided to adapt Metacello to git:)

It is also probably worth reading "What is a good Git workflow?"[2]. This article is more about how to use GitHub, but frankly the appeal of git to me goes hand in hand with a good collaboration model and GitHub does a good job supporting that.

The first time you read these articles don't pay attention to the details, but try to get the overall flow/functionality and try to draw parallels to the work the you do with Monticello and Metacello ... let the thoughts marinate, ask some questions.

"Pro Git"[3] is a book/web site and would recommend that you take a run through Chapter 2[4] to get a taste of git in action at the command line and virtually everything that you need to know to work on your own with git is covered in this chapter. Chapter 3[5] is on the nitty gritty of branching ... but again at this stage you want to just skim through the docs and get a feel of what is possible ... if something doesn't make sense at this stage ... 

ignore it:)

Now go back to the  "What is a good Git workflow?"[2] paper and read it in detail ... if you see a command/operation that you don't understand google it or look it up in "Pro Git" or ask questions ...

Basically I am recommending that for your first foray into Git and Smalltalk you will be trying to follow the  "What is a good Git workflow?"[2] model.

FileTree allows you save Monticello packages into a git repository, but with FileTree you have to do all of the git commands from the command line. 

I'll let Thierry Goubier describe GitFileTree because I think it that package does a bit of remote control ....

I think that it is possible to most if not all of the git work support into the Smalltalk development environment ... I am doing that for GemStone with tODE[6] and I do find myself going to the go to the command line much less frequently ... but in tODE I have built a git merge tool and a git diff tool ... you can get the git history of a method from the browser, etc. 

Without a relatively high degree of tool integration it can be clunky to use git ... I am very willing to share what I've done/learned in tODE with Pharo tool builders and of course I think Thierry Goubier has actually been ahead of me in several different areas ...

Of course there are other git workflows out there and other git collaboration sites besides GitHub...but is worth keeping things simple at first (I think) and when you have mastered git/github basics both personally and from a tool level, then it is a perfectly good time to start looking at other workflows and tools, because then you are able to make informed judgements ...

HTH,

Dale

[1] http://nvie.com/posts/a-successful-git-branching-model/

[2] https://help.github.com/articles/what-is-a-good-git-workflow

[3] http://git-scm.com/book

[4] http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository

[5] http://git-scm.com/book/en/Git-Branching

[6] https://github.com/dalehenrich/tode

On Thu, Jun 26, 2014 at 9:27 AM, stepharo <[hidden email]> wrote:

Hi

I do not know the dif between git file tree, file tree.... and I would like to know how to get
started with git in Pharo?

What should I read?

Stef

Esteban

My old age taught me to be suspicious when everything is so black and
white. I do not think that everything will be so nice.
And for me git is not github.

Stef

On 26/6/14 20:52, Esteban Lorenzano wrote:

I use git for my books. Now the simple fact that a tool has to help me to do simple action is a sign
of strange design. This is the same as Java design and eclipse. When you code without eclipse you will a real pain :)
I found the git API far to low level from my developer perspective and this is what I would like the pharo abstraction to
protect our users (while getting the benefits from git).
And this is why when esteban is telling that this is what newbies expect I cannot believe such kind of statements
because there are simply bullshit. :)

Stef

Stef,

You need to cut your teeth for a decent couple hours to get to terms with Git.

Especially when using a workflow with branches, with merges, and several contributors.

I knew of quite a couple of SCMs (including Hg) but Git is a special beast.

I liked Git Recipes: A Problem Solution Approach as it was very pragmatic.

HTH

Phil

On Thu, Jun 26, 2014 at 7:09 PM, stepharo <[hidden email]> wrote:

I read

http://www.stic.st/wp-content/conferences/2012/Wednesday/1415-Practical_Git_for_Smalltalk-Henrichs.pdf
    and I found
    http://forum.world.st/Pharo-git-td4693999.html

But is there something that works and it simple?

Stef


On 26/6/14 18:27, stepharo wrote:

Hi

I do not know the dif between git file tree, file tree.... and I would like to know how to get
started with git in Pharo?

What should I read?

Stef

thanks

Now is there a tutorial? Beause
http://forum.world.st/Pharo-git-td4693999.html scared me.


On 27/6/14 15:53, Goubier Thierry wrote:

On Jun 28, 2014, at 5:10 AM, stepharo <[hidden email]> wrote:

Stef, all,

First, you need to know how to work with git and understand the vocabulary. Otherwise, you _will_ get confused, and probably get disgusted.
So, beware... git was made for and by linux people, which is all I am going to say about that...

In my experience, tools always help and I can recommend sourcetree [1] or git tower [2].
Reading the links that Dale mentioned is a very good idea too.

Next, Dale's 'getting started with github' [3] is a good intro to make your first git project work and understand the extra steps you need to make to manage source code.
It does not have to be a github project.

Let me also comment a bit on why we (at Yesplan) are now trying to switch from monticello to git for our daily work. I am using git for over a year now and we are actively switching to use it on a daily basis.

First of all, in our daily work, we need continuous deployment. When a feature is ready, it must be shipped into production as soon as possible. If you are not the only one working on a codebase, continuous deployment requires that each feature is developed in its own branch and can only be integrated with the main codebase when it's ready and stable. Monticello just does not support branching well. In Git, this is natural. You can easily create feature branches, do partial publishes, merge the changes from the main codebase back into your feature branch, explore the version history, etc. I must also add that github's pull request and code commenting feature is a very productive way of working together on the same codebase in a structured way.

About a year ago, I almost only used git tools to merge in the changes from Zinc 1.7 to 2.3.2 for the Gemstone port. In that change, Sven made a huge amount of package changes, which is about the worst case scenario to understand any evolution and merge it in a port (which has code changes itself). In about an afternoon of work, most of the dust had settled and I was using the git merge to understand code moves and to prevent gemstone-specific changes from being overwritten again. The best part there was probably the sub-method-level merges. Also, the reason I did not need any Smalltalk browser to do the merges is because filetree exports packages and classes as directories and methods as files. If you use the column layout of the Finder on Mac, the Finder becomes the System Browser (at least for understanding and navigating the structure of the source code, which is what you need at that level). Sourcetree had such a browser internally until very recently... so I am disappointed they removed that.

Besides numerous other projects, we have Seaside hosted in a github repository too. The advantages are that we can test every feature branch and every platform automatically with Travis CI. We don't use pull requests in the community, but if we did, it would be way easier for contributors and maintainers. Forking and pulling makes it easy for people to patch something and contribute the code back, while at the same time, it allows the maintainers to protect the code base from harmful changes.

Finally, the biggest pain with filetree is that it carries the monticello metadata. If you work together on the same branch, you _will_ get stupid merge conflicts on that metadata. Here, Thierry Goubier's FileTreeMerge tool [5] is a wonderful tool. Since I started using that, merges of the metadata are done by git automatically and I just forget about them. Nice work Thierry!

Another pain is that publishing and loading code is a two-step process: files on disk and code in your image. You need to very carefully synchronize these. You may switch a branch on disk but forget to load it in the image, or start publishing code from the image to the disk where a different branch was checked out. This is where better tools for git from within the image will help.

those were my 2 cents ;-)
Johan

[1] http://www.sourcetreeapp.com
[2] http://www.git-tower.com
[3] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStartedWithGitHub.md
[4] https://github.com/glassdb/Seaside31
[5] https://github.com/ThierryGoubier/GitFileTree-MergeDriver

On 28 Jun 2014, at 10:12, stepharo <[hidden email]> wrote:

You just got me convinced to go with Thierry's tooling...

Phil

EstebanLM wrote

- better visibility

+1. I found an online tool that analyzes a person's programming contributions that described me as (paraphrase): "a Javascript expert who dabbles in Smalltalk" or some such nonsense, because it could see my (very) few Amber contributions on GitHub, but was blissfully unaware of my countless MC commits.

Sven Van Caekenberghe-2 wrote

we are on github

I don't think that code mirrored by a robot tells us much about the potential impact of using GitHub the way it was designed - discussions directly in commit diffs; integration of issues, commits, users; a real depiction of who contributed what and when...