If all Pharo projects were on GitHub...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

If all Pharo projects were on GitHub...

abergel
… Pharo may be within the 30 most popular languages on Earth.
The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.

I wish we had a nice Git integration.

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

volkert-2
+1

On 27.09.2015 11:57, Alexandre Bergel wrote:
> … Pharo may be within the 30 most popular languages on Earth.
> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
>
> I wish we had a nice Git integration.
>
> Alexandre


Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

kilon.alios
In reply to this post by abergel
we have more than a nice Git integration. I have been using Github for my pharo project for over a year now without any issue, the last few months I have been using gitfiltree which is making it even easier. Definitely beats the alternatives .

On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel <[hidden email]> wrote:
… Pharo may be within the 30 most popular languages on Earth.
The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.

I wish we had a nice Git integration.

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

abergel
I have tried several times to use Git for my project. But I do not want to spend time on configuring .gitattribute and other configuration file. This does not go in the right direction I believe. Why is it easier to use git with Java than it is with Pharo?

Alexandre


> On Sep 27, 2015, at 12:11 PM, Dimitris Chloupis <[hidden email]> wrote:
>
> we have more than a nice Git integration. I have been using Github for my pharo project for over a year now without any issue, the last few months I have been using gitfiltree which is making it even easier. Definitely beats the alternatives .
>
> On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel <[hidden email]> wrote:
> … Pharo may be within the 30 most popular languages on Earth.
> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
>
> I wish we had a nice Git integration.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

philippe.back@highoctane.be

It isn't. It is actually very easy to use git.

Time for a video :-)

Expect that for tomorrow.

Phil

Le 27 sept. 2015 12:22, "Alexandre Bergel" <[hidden email]> a écrit :
I have tried several times to use Git for my project. But I do not want to spend time on configuring .gitattribute and other configuration file. This does not go in the right direction I believe. Why is it easier to use git with Java than it is with Pharo?

Alexandre


> On Sep 27, 2015, at 12:11 PM, Dimitris Chloupis <[hidden email]> wrote:
>
> we have more than a nice Git integration. I have been using Github for my pharo project for over a year now without any issue, the last few months I have been using gitfiltree which is making it even easier. Definitely beats the alternatives .
>
> On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel <[hidden email]> wrote:
> … Pharo may be within the 30 most popular languages on Earth.
> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
>
> I wish we had a nice Git integration.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

kilon.alios
In reply to this post by abergel
This is the first time I read that one had to customise .gitattribute and other configurations to get git running with pharo. I have never needed to do any of those things, for me its just a matter of doing a single click, for installing gitfiletree. Then I add my git project like any other smalltalkhub project and manage it the same way via monticello.

Maybe describe the exact issues you are having so others can help you out ?

Frankly Pharo is far better than any other language I have used git with. What other language come with IDE included , and one that also integrates with Git out of the box without having to use the terminal ? I dont even remember doing anything the easy way in Java , Python maybe, Java ? nope.

Bottom line is that each has a different experience, you say that Git integration is not nice, I say its the best experience I have every had with any other language. Obviously our experiences are like night and day .

On the other hand I use the very basics of git, just git commit and git push/ pull. Maybe you have found some problems I have not. Please share, report so we can improve.

On Sun, Sep 27, 2015 at 1:22 PM Alexandre Bergel <[hidden email]> wrote:
I have tried several times to use Git for my project. But I do not want to spend time on configuring .gitattribute and other configuration file. This does not go in the right direction I believe. Why is it easier to use git with Java than it is with Pharo?

Alexandre


> On Sep 27, 2015, at 12:11 PM, Dimitris Chloupis <[hidden email]> wrote:
>
> we have more than a nice Git integration. I have been using Github for my pharo project for over a year now without any issue, the last few months I have been using gitfiltree which is making it even easier. Definitely beats the alternatives .
>
> On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel <[hidden email]> wrote:
> … Pharo may be within the 30 most popular languages on Earth.
> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
>
> I wish we had a nice Git integration.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

CyrilFerlicot
In reply to this post by kilon.alios
Le 27/09/2015 12:11, Dimitris Chloupis a écrit :
> we have more than a nice Git integration. I have been using Github for
> my pharo project for over a year now without any issue, the last few
> months I have been using gitfiltree which is making it even easier.
> Definitely beats the alternatives .
>

Hi!

Did you try to use git on a big project with a team? Did you try to
merge .st files ?
I heard it's really annoying to merge files with meta informations on git.

An other point is that git file tree will not work on Windows if we do
not fix the problem of the stdio. And a lot of people out of the
community use Windows, so this is not a issue we should forget. Most of
the people I know in company use Windows, so if we want to attract
people this problem need to be corrected.

> On Sun, Sep 27, 2015 at 12:58 PM Alexandre Bergel
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     … Pharo may be within the 30 most popular languages on Earth.
>     The 30th languages has 3,253 repository. There are 2,635 on
>     SmalltalkHub.
>
>     I wish we had a nice Git integration.
>
>     Alexandre
>     --
>     _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>     Alexandre Bergel  http://www.bergel.eu
>     ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
--
Cheers
Cyril


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

stepharo
In reply to this post by abergel
Alex do you know git?
Because to me git is **really** complex. I do not talk about add push
commit but rebase remote....
Did you try to use sourcetree (the UI for git) to understand what I mean?
So we cannot use git simply we have to propose a much nicer model on top
of this assembly.

Now you can systematicall save your code with monticello and
automatically publish it to git.
Esteban has a script for doing that.

Stef

> … Pharo may be within the 30 most popular languages on Earth.
> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
>
> I wish we had a nice Git integration.
>
> Alexandre


Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

Thierry Goubier
In reply to this post by CyrilFerlicot
Le 27/09/2015 13:12, Ferlicot D. Cyril a écrit :

> Le 27/09/2015 12:11, Dimitris Chloupis a écrit :
>> we have more than a nice Git integration. I have been using Github for
>> my pharo project for over a year now without any issue, the last few
>> months I have been using gitfiltree which is making it even easier.
>> Definitely beats the alternatives .
>>
>
> Hi!
>
> Did you try to use git on a big project with a team? Did you try to
> merge .st files ?
> I heard it's really annoying to merge files with meta informations on git.

> An other point is that git file tree will not work on Windows if we do
> not fix the problem of the stdio. And a lot of people out of the
> community use Windows, so this is not a issue we should forget. Most of
> the people I know in company use Windows, so if we want to attract
> people this problem need to be corrected.

I'd really like people who put Windows as an important platform invest
on making sure what we have for Windows support in Pharo really works.

Thierry

Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

stepharo
Coming back from africa I can say that windows is first then linux.....
and may be 1% mac

>>> we have more than a nice Git integration. I have been using Github for
>>> my pharo project for over a year now without any issue, the last few
>>> months I have been using gitfiltree which is making it even easier.
>>> Definitely beats the alternatives .
>>>
>>
>> Hi!
>>
>> Did you try to use git on a big project with a team? Did you try to
>> merge .st files ?
>> I heard it's really annoying to merge files with meta informations on
>> git.
>
>> An other point is that git file tree will not work on Windows if we do
>> not fix the problem of the stdio. And a lot of people out of the
>> community use Windows, so this is not a issue we should forget. Most of
>> the people I know in company use Windows, so if we want to attract
>> people this problem need to be corrected.
>
> I'd really like people who put Windows as an important platform invest
> on making sure what we have for Windows support in Pharo really works.
>
> Thierry
>
>


Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

EstebanLM
In reply to this post by stepharo
Hi,

I’ve been using git for all my projects since more than one year now, and frankly I found it really good… and the pull request mechanism is unbeatable.
Now, what I do believe is that we need to improve a couple of things:

1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative.
2) double commit is annoying.

We have a decent solution for (2), gitfiletree but is not working fine in windows (and that’s mandatory). I would like a community push here to make it work fine.
Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadn’t commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library).

Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as “just another interchangeable repository for monticello”. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all.
I worked in a replacement for filetree and as a file format it works fine… is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need.

After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :)

So I would do a “call for pushing” and ask community to spend some time making it work properly.
 
cheers,
Esteban


> On 27 Sep 2015, at 13:43, stepharo <[hidden email]> wrote:
>
> Alex do you know git?
> Because to me git is **really** complex. I do not talk about add push commit but rebase remote....
> Did you try to use sourcetree (the UI for git) to understand what I mean?
> So we cannot use git simply we have to propose a much nicer model on top of this assembly.
>
> Now you can systematicall save your code with monticello and automatically publish it to git.
> Esteban has a script for doing that.
>
> Stef
>
>> … Pharo may be within the 30 most popular languages on Earth.
>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
>>
>> I wish we had a nice Git integration.
>>
>> Alexandre
>
>


Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

Peter Uhnak
In reply to this post by stepharo
Because to me git is **really** complex. I do not talk about add push commit but rebase remote....

Git allows you to do complex things if you need them.
But you can easily use git without ever needing rebase, filter-branch or whatnot.

Everything that Monticello can do can be done with git easily (commit, push, pull, merge).
It just gives you much more powerful tools.
Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

Ben Coman
In reply to this post by EstebanLM
On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <[hidden email]> wrote:

> Hi,
>
> I’ve been using git for all my projects since more than one year now, and frankly I found it really good… and the pull request mechanism is unbeatable.
> Now, what I do believe is that we need to improve a couple of things:
>
> 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative.
> 2) double commit is annoying.
>
> We have a decent solution for (2), gitfiletree but is not working fine in windows (and that’s mandatory). I would like a community push here to make it work fine.
> Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadn’t commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library).

Would moving to libgit2 bypass the problem with stdio?

> Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as “just another interchangeable repository for monticello”. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all.
> I worked in a replacement for filetree and as a file format it works fine… is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need.

I have a vague recollection that the problem was a particular file
where data changed each commit and having the idea that this might be
solved by: each commit writing metadata to a different file e.g.
NNNN.metadata, and Monticello knows to pick up the highest numbered
metadata.


> After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :)
>
> So I would do a “call for pushing” and ask community to spend some time making it work properly.
>
> cheers,
> Esteban
>
>
>> On 27 Sep 2015, at 13:43, stepharo <[hidden email]> wrote:
>>
>> Alex do you know git?
>> Because to me git is **really** complex. I do not talk about add push commit but rebase remote....

Git is very flexible which implies complexity for newcomers to it.
What is required on top of git is a "well defined" workflow.    I see
sometimes on this mail-list that people design their tools for
flexibility since they don't want to *impose* a workflow on people,
which is a commendable philosophy, but slows adoption by newcomers.
It may be useful to define "this is *the* way its done here" , with
the standard proviso that there may be missteps that need to be tuned.

cheers -ben


>> Did you try to use sourcetree (the UI for git) to understand what I mean?
>> So we cannot use git simply we have to propose a much nicer model on top of this assembly.
>>
>> Now you can systematicall save your code with monticello and automatically publish it to git.
>> Esteban has a script for doing that.
>>
>> Stef
>>
>>> … Pharo may be within the 30 most popular languages on Earth.
>>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
>>>
>>> I wish we had a nice Git integration.
>>>
>>> Alexandre
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

philippe.back@highoctane.be


Le 28 sept. 2015 04:29, "Ben Coman" <[hidden email]> a écrit :
>
> On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <[hidden email]> wrote:
> > Hi,
> >
> > I’ve been using git for all my projects since more than one year now, and frankly I found it really good… and the pull request mechanism is unbeatable.
> > Now, what I do believe is that we need to improve a couple of things:
> >
> > 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative.
> > 2) double commit is annoying.
> >
> > We have a decent solution for (2), gitfiletree but is not working fine in windows (and that’s mandatory). I would like a community push here to make it work fine.
> > Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadn’t commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library).
>
> Would moving to libgit2 bypass the problem with stdio?
>
> > Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as “just another interchangeable repository for monticello”. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all.
> > I worked in a replacement for filetree and as a file format it works fine… is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need.
>
> I have a vague recollection that the problem was a particular file
> where data changed each commit and having the idea that this might be
> solved by: each commit writing metadata to a different file e.g.
> NNNN.metadata, and Monticello knows to pick up the highest numbered
> metadata.
>
>
> > After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :)
> >
> > So I would do a “call for pushing” and ask community to spend some time making it work properly.
> >
> > cheers,
> > Esteban
> >
> >
> >> On 27 Sep 2015, at 13:43, stepharo <[hidden email]> wrote:
> >>
> >> Alex do you know git?
> >> Because to me git is **really** complex. I do not talk about add push commit but rebase remote....
>
> Git is very flexible which implies complexity for newcomers to it.
> What is required on top of git is a "well defined" workflow.    I see
> sometimes on this mail-list that people design their tools for
> flexibility since they don't want to *impose* a workflow on people,
> which is a commendable philosophy, but slows adoption by newcomers.
> It may be useful to define "this is *the* way its done here" , with
> the standard proviso that there may be missteps that need to be tuned.

Currently working in a distributed team with multiple companies. We use git and also Phabricator for reviews which is really great.

I cant think of *not* using a DVCS and features like git rebase in such an environment.

Phil

>
> cheers -ben
>
>
> >> Did you try to use sourcetree (the UI for git) to understand what I mean?
> >> So we cannot use git simply we have to propose a much nicer model on top of this assembly.
> >>
> >> Now you can systematicall save your code with monticello and automatically publish it to git.
> >> Esteban has a script for doing that.
> >>
> >> Stef
> >>
> >>> … Pharo may be within the 30 most popular languages on Earth.
> >>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
> >>>
> >>> I wish we had a nice Git integration.
> >>>
> >>> Alexandre
> >>
> >>
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

Max Leske
In reply to this post by Ben Coman

> On 28 Sep 2015, at 04:27, Ben Coman <[hidden email]> wrote:
>
> On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <[hidden email]> wrote:
>> Hi,
>>
>> I’ve been using git for all my projects since more than one year now, and frankly I found it really good… and the pull request mechanism is unbeatable.
>> Now, what I do believe is that we need to improve a couple of things:
>>
>> 1) filtree format is not good while working on teams (which is the power of git, after all). Merging is a pain and the merge driver provided by Thierry is just a patch, not a real alternative.
>> 2) double commit is annoying.
>>
>> We have a decent solution for (2), gitfiletree but is not working fine in windows (and that’s mandatory). I would like a community push here to make it work fine.
>> Once is working, I would like to replace the OSProcess usage with actual libgit2. As far as I understand, this is already possible but we hadn’t commit time to make it possible (and I would put it as a secondary goal: first make it work with what we have, then use the library).
>
> Would moving to libgit2 bypass the problem with stdio?

Yes. We call out to libgit2 through NativeBoost.

>
>> Now the filetree format has problems merging because it stores some metadata that we do not really need. The origin of this is the fact that is using git as “just another interchangeable repository for monticello”. IMHO while this was desirable for start, is not a good solution now. We do not need that information at all.
>> I worked in a replacement for filetree and as a file format it works fine… is just a variation who does not stores the not-needed information and relies on STON to manage the one we actually need.
>
> I have a vague recollection that the problem was a particular file
> where data changed each commit and having the idea that this might be
> solved by: each commit writing metadata to a different file e.g.
> NNNN.metadata, and Monticello knows to pick up the highest numbered
> metadata.
>
>
>> After, we can build the actual tools we need. But with that working we will see a lot clearer what we actually need to do :)
>>
>> So I would do a “call for pushing” and ask community to spend some time making it work properly.
>>
>> cheers,
>> Esteban
>>
>>
>>> On 27 Sep 2015, at 13:43, stepharo <[hidden email]> wrote:
>>>
>>> Alex do you know git?
>>> Because to me git is **really** complex. I do not talk about add push commit but rebase remote....
>
> Git is very flexible which implies complexity for newcomers to it.
> What is required on top of git is a "well defined" workflow.    I see
> sometimes on this mail-list that people design their tools for
> flexibility since they don't want to *impose* a workflow on people,
> which is a commendable philosophy, but slows adoption by newcomers.
> It may be useful to define "this is *the* way its done here" , with
> the standard proviso that there may be missteps that need to be tuned.
>
> cheers -ben
>
>
>>> Did you try to use sourcetree (the UI for git) to understand what I mean?
>>> So we cannot use git simply we have to propose a much nicer model on top of this assembly.
>>>
>>> Now you can systematicall save your code with monticello and automatically publish it to git.
>>> Esteban has a script for doing that.
>>>
>>> Stef
>>>
>>>> … Pharo may be within the 30 most popular languages on Earth.
>>>> The 30th languages has 3,253 repository. There are 2,635 on SmalltalkHub.
>>>>
>>>> I wish we had a nice Git integration.
>>>>
>>>> Alexandre
>>>
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

Thierry Goubier
In reply to this post by Ben Coman
Le 28/09/2015 04:27, Ben Coman a écrit :
>
> I have a vague recollection that the problem was a particular file
> where data changed each commit and having the idea that this might be
> solved by: each commit writing metadata to a different file e.g.
> NNNN.metadata, and Monticello knows to pick up the highest numbered
> metadata.

Hum, I thought that as well, but in fact write the merge driver turned
out as far better and simpler. Moreover, all type of data oriented files
(ston, json, version) do not merge properly in git. So even Esteban
saying he will use STON does not seems to solve the merge issue, unless
he is planning something else. I do take in account we will have more
metadata in the future, thanks to EPICEA, so we need a way to handle it.

Merging is easy, you just need to hook into it.

I believed also that we could do the merge ourselves and force git to
commit the result, but discovered this was a bad idea. Imagine having to
fire Pharo to merge a 250k OCaml project with 2k of st code in it :(

> Git is very flexible which implies complexity for newcomers to it.
> What is required on top of git is a "well defined" workflow.    I see
> sometimes on this mail-list that people design their tools for
> flexibility since they don't want to *impose* a workflow on people,
> which is a commendable philosophy, but slows adoption by newcomers.
> It may be useful to define "this is *the* way its done here" , with
> the standard proviso that there may be missteps that need to be tuned.

Unless you have some experience of Monticello, Metacello, the Pharo
workflow, some of the workflow outside Pharo, and git, then defining
this workflow is shooting in the dark. So, first attempts are either:

- be flexible, so that you fit into a pre-existing workflow, and explore
options,

- be dictatorial in your shot in the dark, and pray you got it right.

Now, we've solved all the hard points (apart from the Windows support),
so we can imagine a future.

Thierry

Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

stepharo
In reply to this post by Peter Uhnak


Le 27/9/15 15:33, Peter Uhnák a écrit :
Because to me git is **really** complex. I do not talk about add push commit but rebase remote....

Git allows you to do complex things if you need them.
But you can easily use git without ever needing rebase, filter-branch or whatnot.

Everything that Monticello can do can be done with git easily (commit, push, pull, merge).
It just gives you much more powerful tools.

sure except that suddenly you do not know why you have to know the arcanes part.
I think that git is not layered so you get exposed to a lot of details even when you avoid.
May be having a set of git macros would help.

Stef

Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

Thierry Goubier


2015-09-28 8:53 GMT+02:00 stepharo <[hidden email]>:


Le 27/9/15 15:33, Peter Uhnák a écrit :
Because to me git is **really** complex. I do not talk about add push commit but rebase remote....

Git allows you to do complex things if you need them.
But you can easily use git without ever needing rebase, filter-branch or whatnot.

Everything that Monticello can do can be done with git easily (commit, push, pull, merge).
It just gives you much more powerful tools.

sure except that suddenly you do not know why you have to know the arcanes part.
I think that git is not layered so you get exposed to a lot of details even when you avoid.

You probably nailed it when it comes to why git seems more complex that needs to be.
 
May be having a set of git macros would help. 
 
Maybe not because macros are fragile and your average set of git commands is rather limited. Making git simpler through Pharo could be nice...

Thierry
Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

Peter Uhnak
sure except that suddenly you do not know why you have to know the arcanes part. 
I think that git is not layered so you get exposed to a lot of details even when you avoid.

Hmm, I don't see that, but I've been using git for many years so I am not in position to judge it how complex it is.
 
May be having a set of git macros would help. 
 
Maybe not because macros are fragile and your average set of git commands is rather limited. Making git simpler through Pharo could be nice...

Maybe providing a way to streamline common patterns.

For example in git community there's a well known workflow model http://nvie.com/posts/a-successful-git-branching-model/
There's even git extension (but you can still use git directly) on top of that pattern https://github.com/nvie/gitflow (better visualized here https://danielkummer.github.io/git-flow-cheatsheet/ )

And while most don't follow the pattern strictly, most people are at least inspired by it and adapt parts of it.

Peter



Reply | Threaded
Open this post in threaded view
|

Re: If all Pharo projects were on GitHub...

Damien Cassou-2
In reply to this post by abergel

Alexandre Bergel <[hidden email]> writes:

> I have tried several times to use Git for my project. But I do not
> want to spend time on configuring .gitattribute and other
> configuration file. This does not go in the right direction I believe.
> Why is it easier to use git with Java than it is with Pharo?

I disagree, I think configuring .gitattribute (for the merge driver) is
an important step forward. It means that Pharo can control the merge.
Currently, it's only useful for metadata. But later, it might be useful
to facilitate code merges: e.g., a method is renamed in a branch and
improved in another. This should not generate a conflict. With Epicea,
we might be able to avoid this conflict in the future and drive the
merge successfully.

Another example: two branches each adds an instance variable to the same
class. This should not generate a conflict. The merge driver could
detect that and merge successfully.

Final example: the merge driver could run the unit tests while merging
to tell the developer when a merge is correct and when it is not.

The merge driver means we can merge ASTs, not lines of source code.

For me, the merge driver is the future, not the past. Thanks Thierry.


--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

123