Re: [Pharo-dev] How to get started with Git and Pharo?

[Sean P. DeNigris]

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...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p4765527.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sean P. DeNigris]

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.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p4765526.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] How to get started with Git and Pharo?

[p...@highoctane.be]

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

Phil
Le 28 juin 2014 17:13, "Johan Brichau"  a écrit :

> 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  wrote:
>
> > 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:
> >>
> >>
> >> 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 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Johan Brichau]

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  wrote:

> 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:
>> 
>> 
>> 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
> 
> 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Dale Henrichs]

Stef,

Git is not perfect. Monticello is not perfect. Metacello is not perfect.
GitHub is not perfect.

Git and Github brings some things to the table that make Monticello and
Metacello and collaborative development in Smalltalk better...

Half of Metacello - the bit where you must "manually" record the version
number for every .mcz file used - one of the most tedious parts - becomes
unnecessary with git. With git a Metacello version references a specific
commit, tag or branch.

When we release a version of Seaside3 for GemStone, we just tag a
repository and record the tag in the configuration of ... no need for
"flattening" or meticulously recording of mcz file versions ... this simple
fact by itself is almost enough to make the "complexity of git"
worthwhile... Here's the complete version specification for Seaside3.1.1 in
the ConfigurationOfSeaside3:

  spec
for: #'gs3.x'
do: [
  spec
baseline: 'Seaside3'
with: [ spec repository:
'github://glassdb/Seaside31:3.1.1-gs31/repository' ] ].

That's it ... done...

95% of my git interactions are:

  git add ...
  git commit ...
  git push ...
  git pull ...


This isn't that complicated to understand ... there are certainly times
when it is necessary to use some of the more arcane commands, but frankly
there are complicated operations in the Monticello/Metacello universe.

How do you merge two Metacello versions?
How do you merge changes to multiple mcz files?
How do you fork/branch a large project like Seaside3 and still retain the
ability to track changes from the master?

I have done all of these things without git and it is not pretty  not
by a long shot...I wish we did have some arcane commands to help:)

With git, all three of those operations are just part of eco-system...

With github, I can merge a multiple mcz file contribution into my project
 ... WITH THE PUSH OF A BUTTON!

GiHub arranges to run the tests using travis-ci, so before I dare push the
button, I can be assured that all of the tests are passing.

Before pushing the button, I can easily review all of the proposed changes
and critique the proposed changes on a line by line basis and the
contributor and I can engage in an online conversion ... on a line by line
basis ...

The contributor can make changes in her repository and they are reflected
in the original pull request and the tests are automatically rerun...

When the tests are green and I am satisfied with the review ... I press a
button ... and the code is merged into my project and I can go back to work
...

_This_ feature by itself is worth the price of admission for git ...

It takes a bit of time to become comfortable with git, but if you are
feeling any of pain that I have mentioned above, then it is worth taking
the time to become comfortable with git ...

If you are not feeling that pain, then I envy you:) and by all means ... do
not learn git:)

Dale



On Sat, Jun 28, 2014 at 1:10 AM, stepharo  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  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
>>>
>>
>>
>>
>
>

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sebastian Sastre]

On Jun 28, 2014, at 5:10 AM, stepharo  wrote:

> 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. :)

Hey Stef, we can believe that is bullshit all we want and at the end of the day 
this is what happens:

Software Engineers Are In Demand, And GitHub Is How You Find Them
http://www.forbes.com/sites/anthonykosner/2012/10/20/software-engineers-are-in-demand-and-github-is-how-you-find-them/

How to Recruit Using Github, Quora, Dribbble & More
http://www.slideshare.net/VivekReddy4/how-to-recruit-using-github-quora-dribbble-more

With the current demand, if you weren’t pitched yet from your github profile is 
because you’re forcing yourself to stay out of the game

sebastian

o/

blog: http://sebastianconcept.com
LinkedIn: http://www.linkedin.com/in/sebastiansastre
github: https://github.com/sebastianconcept

Re: [Pharo-dev] How to get started with Git and Pharo?

[stepharo]

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:



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

Re: [Pharo-dev] How to get started with Git and Pharo?

[stepharo]

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 > 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

Re: [Pharo-dev] How to get started with Git and Pharo?

[stepharo]

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:

On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:


On 26 Jun 2014, at 19:07, Dale Henrichs  
wrote:


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 ...

That is my analysis: it works today, 'perfectly', but there is not enough tools 
support to make it as easy as Monticello as a whole is today.

If these tools exist, or we can build them quickly based Dale's code, that 
would be cool (I guess its all OSProcess underneath, which I find so/so, a 
direct integration is better) that would be good.

Would having this change our world fundamentally ? No, IMHO
Is it worth the effort, is the ROI there ? I don't think so

I disagree here. I think moving our development to git will change deeply (for 
good) our community processes and then I think it totally worths the effort.
Of course, important part of the advantages came from the tools around git 
(like github) more than git itself, but all is one and the same :)
A couple of examples of what I think will improve our work:
- pull requests instead SLICES
- submodules (with different people taking care of them)
- traceability: you can map an issue with a pull requests directly making it a 
lot better to query

Then there is other kind of advantages like:
- better entry-point for newbies to the community (they all expect something 
like git this days)
- better visibility
- confidence. This is subjective but important: companies feel more confident 
with something like git than a specific tool to keep their sources.
- we can stop maintaining things like smalltalkhub and important parts of 
monticello itself and concentrate our efforts in other, more interesting areas

… and there are more.

In conclusion, I think expending time in git integration is one of the best 
ways to contribute to the develop of Pharo nowadays.

Esteban


Anyway, it is a delicate subject as it also touches on the representation of 
the file format.

Re: [Pharo-dev] How to get started with Git and Pharo?

[stepharo]

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

On 26/6/14 19:07, Dale Henrichs wrote:

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 > 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

Re: [Pharo-dev] How to get started with Git and Pharo?

[Yuriy Tymchuk]

On 27 Jun 2014, at 15:53, Goubier Thierry  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!

> 
> 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
> 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Goubier Thierry]

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

Re: [Pharo-dev] How to get started with Git and Pharo?

[Goubier Thierry]

Hi Stéphane,

I have to admit then that my presentation to you a month ago was a 
failure ;)


Thierry

Le 26/06/2014 18:27, stepharo a écrit :

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




--
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

Re: [Pharo-dev] How to get started with Git and Pharo?

[Goubier Thierry]

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)


Because I haven't spent the time updating the configuration for that :(

I'm pushing small changes on GitFileTree at the moment; a Pharo4 version 
should come soon.


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

Re: [Pharo-dev] How to get started with Git and Pharo?

[Dale Henrichs]

Sven,

You don't believe that it is worthwhile ... that's okay ... you are
entitled to your beliefs.

Frankly, when you integrate git into a Smalltalk environment (and I have)
you are not messing with 100's of little files ... you are working with
methods and packages and classes ... the stuff that Smalltalk programmers
work with every day ... and I don't even think about how the source is
being stored because in my environment I work with methods, classes and
packages and I rarely look at the disk (just like most Smalltalk
programmers and unlike most Java/C#/Go programmers:)...

Git brings another dimension to my smalltalk development experience in a
couple of very critical areas, so I don't have to believe, I know...

I do believe that it is worthwhile to integrate git into Smalltalk
development environments and I'm doing something about that and I am
willing to help other folks with similar beliefs ...

So at the end of the day you can be as negative or as positive as you like
and I will continue to plug away:)

Dale






On Thu, Jun 26, 2014 at 2:04 PM, Sven Van Caekenberghe  wrote:

>
> On 26 Jun 2014, at 22:28, p...@highoctane.be wrote:
>
> >
> > Le 26 juin 2014 21:54, "Esteban Lorenzano"  a
> écrit :
> > >
> > >
> > > On 26 Jun 2014, at 16:38, Sven Van Caekenberghe  wrote:
> > >
> > > > I know you, and some others, have that opinion and that is OK.
> > > > I also think that it would be nice to have (better git integration).
> > > >
> > > > But we essentially have it today, although a bit cumbersome, awkward
> (cfr https://github.com/pharo-project/pharo-core). Some of us store all
> their code in git all the time.
> > > >
> > > > My opinion is that it is not per se the most important thing. We
> have to focus on the aspects where we are better, not try being more the
> same as everybody else.
> > > >
> > > > We need modularisation, better tools, new ways of working with live
> objects, new interactive representations, mouldable tools, remote image
> tools, automatic cloud deploys, magic stuff, ..
> > >
> > > yes… and better git integration is part of “better tools”.
> > > and IMO, with the “plus” that it can boost the other areas.
> >
> > Yes, Git enables all of code and assets in one single place and tooling
> that helps a lot with changes ( e.g. gitk ). That is huge in practice.
>
> I know that there are lots of git tools out there, but how do these help -
> they are disconnected from the image, and thus disconnected from our
> regular way of working (senders, implementors, references, ...).
>
> The current source code format in git is cool, but can you manage a merge
> or diff like that, with all the different parts scattered over 10s, 100s of
> files, with no matter what tool ? Apart from the fact that such bigger
> merge is always very difficult, no other tools will support our world view,
> ever.
>
>
> https://github.com/pharo-project/pharo-core/commit/a4c40ae92c67b2d4d63635d89dac0f7bbaa214d5
>
> You and I understand the above, no Java/C#/Go programmer will.
>
> The next discussion will be: what are all those silly method files, why
> not put them all in one file ? Then the question is, what are all those
> silly exclamation marks in our file out format ? And so on.
>
> I don't want to sound too negative, I just don't belief it will actually
> make that much difference.
>
> > Phil
> >
> > >
> > > Esteban
> > >
> > > >
> > > > On 26 Jun 2014, at 20:52, Esteban Lorenzano 
> wrote:
> > > >
> > > >>
> > > >> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe 
> wrote:
> > > >>
> > > >>>
> > > >>> On 26 Jun 2014, at 19:07, Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
> > > >>>
> > >  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 ...
> > > >>>
> > > >>> That is my analysis: it works today, 'perfectly', but there is not
> enough tools support to make it as easy as Monticello as a whole is today.
> > > >>>
> > > >>> If these tools exist, or we can build them quickly based Dale's
> code, that would be cool (I guess its all OSProcess underneath, which I
> find so/so, a direct integration is better) that would be good.
> > > >>>
> > > >>> Would having this change our world fundamentally ? No, IMHO
> > > >>> Is it worth the effort, is the ROI there ? I don't think so
> > > >>
> > > >> I disagree here. I think moving our development to git will change
> deeply (for good) our co

Re: [Pharo-dev] How to get started with Git and Pharo?

[Richard Sargent]

Sven Van Caekenberghe-2 wrote
> The current source code format in git is cool, but can you manage a merge
> or diff like that, with all the different parts scattered over 10s, 100s
> of files, with no matter what tool ? Apart from the fact that such bigger
> merge is always very difficult, no other tools will support our world
> view, ever. 
> 
> ...
> 
> I don't want to sound too negative, I just don't belief it will actually
> make that much difference.

I've seen the work that Dale's done with tODE. Can you manage a merge with
so many files? Yes, without a doubt. Does git do an excellent job of merging
and differencing? Absolutely.


In terms of making a difference, I'm of the opinion that git provides
something modern, universal, and comparable to ENVY (which I have used for
most of the last 20 years and admire immensely).

Are there more important things to do? Without a doubt. Is this worth too
little to bother with? Absolutely not. git will facilitate configuration
management (not just versionning) and will also greatly facilitate
cross-dialect compatibility. The ability to easily pick up an offering from
one Smalltalk and fork it with small changes for another dialect will be
nirvana for many of us.





--
View this message in context: 
http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p4765178.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sebastian Sastre]

On Jun 26, 2014, at 7:58 PM, Sven Van Caekenberghe  wrote:

> @Sebastian
> 
> So we are on github, gemstone even more, cuis too. And Squeak is not. Did 
> anything change dramatically ?
> 
> There are thousands of languages and systems on github, I like it too, but 
> just being there makes little difference. It is just a tool, a good one, but 
> no more.

It’s a tool that isn’t too interesting as tool

But it is in the part that it leverages the social aspect of coding

Dramatic changes why expect that?

You are only creating the chances to make your code more accessible and less 
alien to fresh eyes

Did I say social already? 

Should say social one more time? like when people talk about things and 
collaboration might emerge?

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sven Van Caekenberghe]

That is cool, but you/we can do that today, Pharo's full source is on github 
for quite some time now.

@Sebastian

So we are on github, gemstone even more, cuis too. And Squeak is not. Did 
anything change dramatically ?

There are thousands of languages and systems on github, I like it too, but just 
being there makes little difference. It is just a tool, a good one, but no more.

On 27 Jun 2014, at 00:16, Dale Henrichs  
wrote:

> My favorite feature by far is the ability to look at the git history of the 
> methods themselves ... just the other day I had a bug that I was tracking 
> down, and by looking at the git history I discovered that a critical change 
> had been made to that method 1 year 12 days ago ... from that I was able to 
> look at all of the changes to all of the packages that had been made in the 
> same commit (the critical code had not only been moved to a different class 
> but the critical method had been moved to a separate package ... and from 
> that I was able to see that a bug had been introduced when not all of the 
> critical method was moved ... bug fixed ...
> 
> Besides method versions, you can look at the git history for a class, package 
> or metacello project  these are thing that would take a bit of work to 
> accomplish using just Monticello ... and if you were to attempt to do it, the 
> simplest thing to do would be to copy all of the packages into a git 
> repository and just use git:) Frank Shearar wrote some code that did 
> something along these lines a couple of years ago ...
> 
> Dale
> 
> 
> 
> On Thu, Jun 26, 2014 at 2:21 PM, kilon alios  wrote:
> another advantage of git is source code searches. It will essentially allow 
> pharoers to search pharo code online and not just being isolated in their 
> image. The search does not return just a whole library but even code 
> fragments. 
> 
> 
> On Fri, Jun 27, 2014 at 12:17 AM, Sebastian Sastre 
>  wrote:
> 
> On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano  wrote:
> 
>> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 26 Jun 2014, at 19:07, Dale Henrichs  
>>> wrote:
>>> 
 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 ...
>>> 
>>> That is my analysis: it works today, 'perfectly', but there is not enough 
>>> tools support to make it as easy as Monticello as a whole is today.
>>> 
>>> If these tools exist, or we can build them quickly based Dale's code, that 
>>> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
>>> direct integration is better) that would be good.
>>> 
>>> Would having this change our world fundamentally ? No, IMHO
>>> Is it worth the effort, is the ROI there ? I don't think so
>> 
>> I disagree here. I think moving our development to git will change deeply 
>> (for good) our community processes and then I think it totally worths the 
>> effort. 
> 
> 
> big +1 here
> 
> The social benefit of having your code exposed in places like github 
> outweighs by at an astronomical scale the current lack of amazing mergetools
> 
> If your code cannot be exposed without friction you’re done 
> 
> The noise of the jungle of 
> 3-new-libraries-per-day-that-can-be-installed-in-one-shot will make your work 
> invisible
> 
> 
> 
> 
> 
> 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Dale Henrichs]

My favorite feature by far is the ability to look at the git history of the
methods themselves ... just the other day I had a bug that I was tracking
down, and by looking at the git history I discovered that a critical change
had been made to that method 1 year 12 days ago ... from that I was able to
look at all of the changes to all of the packages that had been made in the
same commit (the critical code had not only been moved to a different class
but the critical method had been moved to a separate package ... and from
that I was able to see that a bug had been introduced when not all of the
critical method was moved ... bug fixed ...

Besides method versions, you can look at the git history for a class,
package or metacello project  these are thing that would take a bit of
work to accomplish using just Monticello ... and if you were to attempt to
do it, the simplest thing to do would be to copy all of the packages into a
git repository and just use git:) Frank Shearar wrote some code that did
something along these lines a couple of years ago ...

Dale



On Thu, Jun 26, 2014 at 2:21 PM, kilon alios  wrote:

> another advantage of git is source code searches. It will essentially
> allow pharoers to search pharo code online and not just being isolated in
> their image. The search does not return just a whole library but even code
> fragments.
>
>
> On Fri, Jun 27, 2014 at 12:17 AM, Sebastian Sastre <
> sebast...@flowingconcept.com> wrote:
>
>>
>> On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano 
>> wrote:
>>
>> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
>>
>>
>> On 26 Jun 2014, at 19:07, Dale Henrichs 
>> wrote:
>>
>> 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 ...
>>
>>
>> That is my analysis: it works today, 'perfectly', but there is not enough
>> tools support to make it as easy as Monticello as a whole is today.
>>
>> If these tools exist, or we can build them quickly based Dale's code,
>> that would be cool (I guess its all OSProcess underneath, which I find
>> so/so, a direct integration is better) that would be good.
>>
>> Would having this change our world fundamentally ? No, IMHO
>> Is it worth the effort, is the ROI there ? I don't think so
>>
>>
>> I disagree here. I think moving our development to git will change deeply
>> (for good) our community processes and then I think it totally worths the
>> effort.
>>
>>
>>
>> big +1 here
>>
>> The social benefit of having your code exposed in places like github
>> outweighs by at an astronomical scale the current lack of amazing mergetools
>>
>> If your code cannot be exposed without friction you’re done
>>
>> The noise of the jungle of
>> 3-new-libraries-per-day-that-can-be-installed-in-one-shot *will* make
>> your work invisible
>>
>>
>>
>>
>>
>

Re: [Pharo-dev] How to get started with Git and Pharo?

[kilon alios]

another advantage of git is source code searches. It will essentially allow
pharoers to search pharo code online and not just being isolated in their
image. The search does not return just a whole library but even code
fragments.


On Fri, Jun 27, 2014 at 12:17 AM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

>
> On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano 
> wrote:
>
> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
>
>
> On 26 Jun 2014, at 19:07, Dale Henrichs 
> wrote:
>
> 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 ...
>
>
> That is my analysis: it works today, 'perfectly', but there is not enough
> tools support to make it as easy as Monticello as a whole is today.
>
> If these tools exist, or we can build them quickly based Dale's code, that
> would be cool (I guess its all OSProcess underneath, which I find so/so, a
> direct integration is better) that would be good.
>
> Would having this change our world fundamentally ? No, IMHO
> Is it worth the effort, is the ROI there ? I don't think so
>
>
> I disagree here. I think moving our development to git will change deeply
> (for good) our community processes and then I think it totally worths the
> effort.
>
>
>
> big +1 here
>
> The social benefit of having your code exposed in places like github
> outweighs by at an astronomical scale the current lack of amazing mergetools
>
> If your code cannot be exposed without friction you’re done
>
> The noise of the jungle of
> 3-new-libraries-per-day-that-can-be-installed-in-one-shot *will* make
> your work invisible
>
>
>
>
>

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sebastian Sastre]

On Jun 26, 2014, at 3:52 PM, Esteban Lorenzano  wrote:

> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 26 Jun 2014, at 19:07, Dale Henrichs  
>> wrote:
>> 
>>> 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 ...
>> 
>> That is my analysis: it works today, 'perfectly', but there is not enough 
>> tools support to make it as easy as Monticello as a whole is today.
>> 
>> If these tools exist, or we can build them quickly based Dale's code, that 
>> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
>> direct integration is better) that would be good.
>> 
>> Would having this change our world fundamentally ? No, IMHO
>> Is it worth the effort, is the ROI there ? I don't think so
> 
> I disagree here. I think moving our development to git will change deeply 
> (for good) our community processes and then I think it totally worths the 
> effort. 


big +1 here

The social benefit of having your code exposed in places like github outweighs 
by at an astronomical scale the current lack of amazing mergetools

If your code cannot be exposed without friction you’re done 

The noise of the jungle of 
3-new-libraries-per-day-that-can-be-installed-in-one-shot will make your work 
invisible

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sven Van Caekenberghe]

On 26 Jun 2014, at 22:28, p...@highoctane.be wrote:

> 
> Le 26 juin 2014 21:54, "Esteban Lorenzano"  a écrit :
> >
> >
> > On 26 Jun 2014, at 16:38, Sven Van Caekenberghe  wrote:
> >
> > > I know you, and some others, have that opinion and that is OK.
> > > I also think that it would be nice to have (better git integration).
> > >
> > > But we essentially have it today, although a bit cumbersome, awkward (cfr 
> > > https://github.com/pharo-project/pharo-core). Some of us store all their 
> > > code in git all the time.
> > >
> > > My opinion is that it is not per se the most important thing. We have to 
> > > focus on the aspects where we are better, not try being more the same as 
> > > everybody else.
> > >
> > > We need modularisation, better tools, new ways of working with live 
> > > objects, new interactive representations, mouldable tools, remote image 
> > > tools, automatic cloud deploys, magic stuff, ..
> >
> > yes… and better git integration is part of “better tools”.
> > and IMO, with the “plus” that it can boost the other areas.
> 
> Yes, Git enables all of code and assets in one single place and tooling that 
> helps a lot with changes ( e.g. gitk ). That is huge in practice.

I know that there are lots of git tools out there, but how do these help - they 
are disconnected from the image, and thus disconnected from our regular way of 
working (senders, implementors, references, ...).

The current source code format in git is cool, but can you manage a merge or 
diff like that, with all the different parts scattered over 10s, 100s of files, 
with no matter what tool ? Apart from the fact that such bigger merge is always 
very difficult, no other tools will support our world view, ever. 

https://github.com/pharo-project/pharo-core/commit/a4c40ae92c67b2d4d63635d89dac0f7bbaa214d5

You and I understand the above, no Java/C#/Go programmer will.

The next discussion will be: what are all those silly method files, why not put 
them all in one file ? Then the question is, what are all those silly 
exclamation marks in our file out format ? And so on.

I don't want to sound too negative, I just don't belief it will actually make 
that much difference.

> Phil
> 
> >
> > Esteban
> >
> > >
> > > On 26 Jun 2014, at 20:52, Esteban Lorenzano  wrote:
> > >
> > >>
> > >> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
> > >>
> > >>>
> > >>> On 26 Jun 2014, at 19:07, Dale Henrichs 
> > >>>  wrote:
> > >>>
> >  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 ...
> > >>>
> > >>> That is my analysis: it works today, 'perfectly', but there is not 
> > >>> enough tools support to make it as easy as Monticello as a whole is 
> > >>> today.
> > >>>
> > >>> If these tools exist, or we can build them quickly based Dale's code, 
> > >>> that would be cool (I guess its all OSProcess underneath, which I find 
> > >>> so/so, a direct integration is better) that would be good.
> > >>>
> > >>> Would having this change our world fundamentally ? No, IMHO
> > >>> Is it worth the effort, is the ROI there ? I don't think so
> > >>
> > >> I disagree here. I think moving our development to git will change 
> > >> deeply (for good) our community processes and then I think it totally 
> > >> worths the effort.
> > >> Of course, important part of the advantages came from the tools around 
> > >> git (like github) more than git itself, but all is one and the same :)
> > >> A couple of examples of what I think will improve our work:
> > >> - pull requests instead SLICES
> > >> - submodules (with different people taking care of them)
> > >> - traceability: you can map an issue with a pull requests directly 
> > >> making it a lot better to query
> > >>
> > >> Then there is other kind of advantages like:
> > >> - better entry-point for newbies to the community (they all expect 
> > >> something like git this days)
> > >> - better visibility
> > >> - confidence. This is subjective but important: companies feel more 
> > >> confident with something like git than a specific tool to keep their 
> > >> sources.
> > >> - we can stop maintaining things like smalltalkhub and important parts 
> > >> of monticello itself and concentrate our efforts in other, more 
> > >> interesting areas
> > >>
> > >> … and there are more.
> > >>
> > >> In conclusion, I think e

Re: [Pharo-dev] How to get started with Git and Pharo?

[p...@highoctane.be]

Le 26 juin 2014 21:54, "Esteban Lorenzano"  a écrit :
>
>
> On 26 Jun 2014, at 16:38, Sven Van Caekenberghe  wrote:
>
> > I know you, and some others, have that opinion and that is OK.
> > I also think that it would be nice to have (better git integration).
> >
> > But we essentially have it today, although a bit cumbersome, awkward
(cfr https://github.com/pharo-project/pharo-core). Some of us store all
their code in git all the time.
> >
> > My opinion is that it is not per se the most important thing. We have
to focus on the aspects where we are better, not try being more the same as
everybody else.
> >
> > We need modularisation, better tools, new ways of working with live
objects, new interactive representations, mouldable tools, remote image
tools, automatic cloud deploys, magic stuff, ..
>
> yes… and better git integration is part of “better tools”.
> and IMO, with the “plus” that it can boost the other areas.

Yes, Git enables all of code and assets in one single place and tooling
that helps a lot with changes ( e.g. gitk ). That is huge in practice.

Phil

>
> Esteban
>
> >
> > On 26 Jun 2014, at 20:52, Esteban Lorenzano  wrote:
> >
> >>
> >> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
> >>
> >>>
> >>> On 26 Jun 2014, at 19:07, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:
> >>>
>  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 ...
> >>>
> >>> That is my analysis: it works today, 'perfectly', but there is not
enough tools support to make it as easy as Monticello as a whole is today.
> >>>
> >>> If these tools exist, or we can build them quickly based Dale's code,
that would be cool (I guess its all OSProcess underneath, which I find
so/so, a direct integration is better) that would be good.
> >>>
> >>> Would having this change our world fundamentally ? No, IMHO
> >>> Is it worth the effort, is the ROI there ? I don't think so
> >>
> >> I disagree here. I think moving our development to git will change
deeply (for good) our community processes and then I think it totally
worths the effort.
> >> Of course, important part of the advantages came from the tools around
git (like github) more than git itself, but all is one and the same :)
> >> A couple of examples of what I think will improve our work:
> >> - pull requests instead SLICES
> >> - submodules (with different people taking care of them)
> >> - traceability: you can map an issue with a pull requests directly
making it a lot better to query
> >>
> >> Then there is other kind of advantages like:
> >> - better entry-point for newbies to the community (they all expect
something like git this days)
> >> - better visibility
> >> - confidence. This is subjective but important: companies feel more
confident with something like git than a specific tool to keep their
sources.
> >> - we can stop maintaining things like smalltalkhub and important parts
of monticello itself and concentrate our efforts in other, more interesting
areas
> >>
> >> … and there are more.
> >>
> >> In conclusion, I think expending time in git integration is one of the
best ways to contribute to the develop of Pharo nowadays.
> >>
> >> Esteban
> >>
> >>>
> >>> Anyway, it is a delicate subject as it also touches on the
representation of the file format.
> >
> >
>
>

Re: [Pharo-dev] How to get started with Git and Pharo?

[Esteban Lorenzano]

On 26 Jun 2014, at 16:38, Sven Van Caekenberghe  wrote:

> I know you, and some others, have that opinion and that is OK.
> I also think that it would be nice to have (better git integration).
> 
> But we essentially have it today, although a bit cumbersome, awkward (cfr 
> https://github.com/pharo-project/pharo-core). Some of us store all their code 
> in git all the time.
> 
> My opinion is that it is not per se the most important thing. We have to 
> focus on the aspects where we are better, not try being more the same as 
> everybody else.
> 
> We need modularisation, better tools, new ways of working with live objects, 
> new interactive representations, mouldable tools, remote image tools, 
> automatic cloud deploys, magic stuff, ..

yes… and better git integration is part of “better tools”. 
and IMO, with the “plus” that it can boost the other areas.

Esteban  

> 
> On 26 Jun 2014, at 20:52, Esteban Lorenzano  wrote:
> 
>> 
>> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 26 Jun 2014, at 19:07, Dale Henrichs  
>>> wrote:
>>> 
 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 ...
>>> 
>>> That is my analysis: it works today, 'perfectly', but there is not enough 
>>> tools support to make it as easy as Monticello as a whole is today.
>>> 
>>> If these tools exist, or we can build them quickly based Dale's code, that 
>>> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
>>> direct integration is better) that would be good.
>>> 
>>> Would having this change our world fundamentally ? No, IMHO
>>> Is it worth the effort, is the ROI there ? I don't think so
>> 
>> I disagree here. I think moving our development to git will change deeply 
>> (for good) our community processes and then I think it totally worths the 
>> effort. 
>> Of course, important part of the advantages came from the tools around git 
>> (like github) more than git itself, but all is one and the same :)
>> A couple of examples of what I think will improve our work: 
>> - pull requests instead SLICES 
>> - submodules (with different people taking care of them)
>> - traceability: you can map an issue with a pull requests directly making it 
>> a lot better to query
>> 
>> Then there is other kind of advantages like: 
>> - better entry-point for newbies to the community (they all expect something 
>> like git this days)
>> - better visibility 
>> - confidence. This is subjective but important: companies feel more 
>> confident with something like git than a specific tool to keep their 
>> sources. 
>> - we can stop maintaining things like smalltalkhub and important parts of 
>> monticello itself and concentrate our efforts in other, more interesting 
>> areas
>> 
>> … and there are more. 
>> 
>> In conclusion, I think expending time in git integration is one of the best 
>> ways to contribute to the develop of Pharo nowadays.
>> 
>> Esteban
>> 
>>> 
>>> Anyway, it is a delicate subject as it also touches on the representation 
>>> of the file format.
> 
> 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sven Van Caekenberghe]

I know you, and some others, have that opinion and that is OK.
I also think that it would be nice to have (better git integration).

But we essentially have it today, although a bit cumbersome, awkward (cfr 
https://github.com/pharo-project/pharo-core). Some of us store all their code 
in git all the time.

My opinion is that it is not per se the most important thing. We have to focus 
on the aspects where we are better, not try being more the same as everybody 
else.

We need modularisation, better tools, new ways of working with live objects, 
new interactive representations, mouldable tools, remote image tools, automatic 
cloud deploys, magic stuff, ..
 
On 26 Jun 2014, at 20:52, Esteban Lorenzano  wrote:

> 
> On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 26 Jun 2014, at 19:07, Dale Henrichs  
>> wrote:
>> 
>>> 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 ...
>> 
>> That is my analysis: it works today, 'perfectly', but there is not enough 
>> tools support to make it as easy as Monticello as a whole is today.
>> 
>> If these tools exist, or we can build them quickly based Dale's code, that 
>> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
>> direct integration is better) that would be good.
>> 
>> Would having this change our world fundamentally ? No, IMHO
>> Is it worth the effort, is the ROI there ? I don't think so
> 
> I disagree here. I think moving our development to git will change deeply 
> (for good) our community processes and then I think it totally worths the 
> effort. 
> Of course, important part of the advantages came from the tools around git 
> (like github) more than git itself, but all is one and the same :)
> A couple of examples of what I think will improve our work: 
> - pull requests instead SLICES 
> - submodules (with different people taking care of them)
> - traceability: you can map an issue with a pull requests directly making it 
> a lot better to query
> 
> Then there is other kind of advantages like: 
> - better entry-point for newbies to the community (they all expect something 
> like git this days)
> - better visibility 
> - confidence. This is subjective but important: companies feel more confident 
> with something like git than a specific tool to keep their sources. 
> - we can stop maintaining things like smalltalkhub and important parts of 
> monticello itself and concentrate our efforts in other, more interesting areas
> 
> … and there are more. 
> 
> In conclusion, I think expending time in git integration is one of the best 
> ways to contribute to the develop of Pharo nowadays.
> 
> Esteban
> 
>> 
>> Anyway, it is a delicate subject as it also touches on the representation of 
>> the file format.

Re: [Pharo-dev] How to get started with Git and Pharo?

[Esteban Lorenzano]

On 26 Jun 2014, at 14:56, Sven Van Caekenberghe  wrote:

> 
> On 26 Jun 2014, at 19:07, Dale Henrichs  
> wrote:
> 
>> 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 ...
> 
> That is my analysis: it works today, 'perfectly', but there is not enough 
> tools support to make it as easy as Monticello as a whole is today.
> 
> If these tools exist, or we can build them quickly based Dale's code, that 
> would be cool (I guess its all OSProcess underneath, which I find so/so, a 
> direct integration is better) that would be good.
> 
> Would having this change our world fundamentally ? No, IMHO
> Is it worth the effort, is the ROI there ? I don't think so

I disagree here. I think moving our development to git will change deeply (for 
good) our community processes and then I think it totally worths the effort. 
Of course, important part of the advantages came from the tools around git 
(like github) more than git itself, but all is one and the same :)
A couple of examples of what I think will improve our work: 
- pull requests instead SLICES 
- submodules (with different people taking care of them)
- traceability: you can map an issue with a pull requests directly making it a 
lot better to query

Then there is other kind of advantages like: 
- better entry-point for newbies to the community (they all expect something 
like git this days)
- better visibility 
- confidence. This is subjective but important: companies feel more confident 
with something like git than a specific tool to keep their sources. 
- we can stop maintaining things like smalltalkhub and important parts of 
monticello itself and concentrate our efforts in other, more interesting areas

… and there are more. 

In conclusion, I think expending time in git integration is one of the best 
ways to contribute to the develop of Pharo nowadays.

Esteban

> 
> Anyway, it is a delicate subject as it also touches on the representation of 
> the file format.
> 
> 

Re: [Pharo-dev] How to get started with Git and Pharo?

[Sven Van Caekenberghe]

On 26 Jun 2014, at 19:07, Dale Henrichs  
wrote:

> 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 ...

That is my analysis: it works today, 'perfectly', but there is not enough tools 
support to make it as easy as Monticello as a whole is today.

If these tools exist, or we can build them quickly based Dale's code, that 
would be cool (I guess its all OSProcess underneath, which I find so/so, a 
direct integration is better) that would be good.

Would having this change our world fundamentally ? No, IMHO
Is it worth the effort, is the ROI there ? I don't think so

Anyway, it is a delicate subject as it also touches on the representation of 
the file format.

Re: [Pharo-dev] How to get started with Git and Pharo?

[p...@highoctane.be]

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  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
>>
>
>
>

Re: [Pharo-dev] How to get started with Git and Pharo?

[Yuriy Tymchuk]

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)

Uko

On 26 Jun 2014, at 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
> 

Re: [Pharo-dev] How to get started with Git and Pharo?

[stepharo]

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

Re: [Pharo-dev] How to get started with Git and Pharo?

[Dale Henrichs]

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  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
>
>

[Pharo-dev] How to get started with Git and Pharo?

[stepharo]

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