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 <[email protected]> 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 <[email protected]> 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
>>>
>>
>>
>>
>
>
