Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Dale Henrichs]

Excellent!

On 09/30/2015 11:36 PM, Nicolai Hess wrote:



2015-10-01 6:33 GMT+02:00 Jan Vrany >:


On Mon, 2015-09-28 at 16:48 -0700, Dale Henrichs wrote:
> The big issue for git and windows (in general) is that there is
a 255
> character limit on the paths for files  I recently pruned some
> file names for Metacello (on a win-hack branch) just to get
Metacello
> to work with filetree ..

The limit is actually 260 characters. Not that it helps much :-)
However, there's a way (well, hack) to overcome this limit
using special UNC pathnames like
\\?\C:\very\long\path\here or \\?\UNC\server\share\very\long\path.


This hack is now implemented in the latest squeak and pharo vm.


The "only" issue is that not all tools in the chain are using
this hack...

Jan

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Damien Cassou]

Alexandre Bergel  writes:

> Why not having just one folder level? As we would have in any other
> language?

that's not true. In java, a Java path typically looks like:

project/src/main/java/org/apache/project/base/model/MyModel.java

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

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[philippe.b...@highoctane.be]

Le 1 oct. 2015 13:21, "Damien Cassou"  a écrit :
>
>
> Alexandre Bergel  writes:
>
> > Why not having just one folder level? As we would have in any other
> > language?
>
> that's not true. In java, a Java path typically looks like:
>
> project/src/main/java/org/apache/project/base/model/MyModel.java

Same boat for PHP when using frameworks like ZendFramework2.

Namespaces are in, along with composer modules etc. So looong pathes.

Phil
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Alexandre Bergel]

>> Why not having just one folder level? As we would have in any other
>> language?
> 
> that's not true. In java, a Java path typically looks like:
> 
> project/src/main/java/org/apache/project/base/model/MyModel.java

I sincerely wish we had a good git integration. The train is passing by.

Alexandre

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Nicolai Hess]

2015-10-01 6:33 GMT+02:00 Jan Vrany :

> On Mon, 2015-09-28 at 16:48 -0700, Dale Henrichs wrote:
> > The big issue for git and windows (in general) is that there is a 255
> > character limit on the paths for files  I recently pruned some
> > file names for Metacello (on a win-hack branch) just to get Metacello
> > to work with filetree ..
>
> The limit is actually 260 characters. Not that it helps much :-)
> However, there's a way (well, hack) to overcome this limit
> using special UNC pathnames like
> \\?\C:\very\long\path\here or \\?\UNC\server\share\very\long\path.
>

This hack is now implemented in the latest squeak and pharo vm.


>
> The "only" issue is that not all tools in the chain are using
> this hack...
>
> Jan
>
>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Alexandre Bergel]

Why not having just one  folder level? As we would have in any other language? 
One folder per package, and inside a .st file per class. 

Alexandre 

> Le 30 sept. 2015 à 18:47, Dale Henrichs  a 
> écrit :
> 
> 
> 
>> On 09/29/2015 01:50 AM, Henrik Johansen wrote:
>> 
>>> On 29 Sep 2015, at 1:48 , Dale Henrichs  
>>> wrote:
>>> 
>>> The big issue for git and windows (in general) is that there is a 255 
>>> character limit on the paths for files  I recently pruned some file 
>>> names for Metacello (on a win-hack branch) just to get Metacello to work 
>>> with filetree .. 
>>> 
>>> Working with Github Desktop[1] for Windows makes the experience of using 
>>> git from the command line tolerable on Windows - you get a retty nice bash 
>>> shell to work with so as a non-windows user I can work in a pretty familiar 
>>> environment ...
>>> 
>>> At the moment I'm working with Pharo3.0 on Windows, so I don't have any 
>>> useful feedback right now (assuming things have changed a bit on Windows 
>>> with Pharo4.0 and Pharo5.0) ...
>>> 
>>> Dale
>> 
>> IIRC, there is some flag you can set to make (some?) the actual git client 
>> (but not bundled tools)  support long filenames on Windows:
>> git config core.longpaths true
>> For instance, cloning the PharoVM repo choked (or rather, failed 
>> semi-silently) on some really long selector in an obscure plugin somewhere 
>> until I found that...
> 
> Thanks Henry, I have done the `git config core.longpaths true` and I believe 
> that that (supposedly) addresses manipulating long file paths problem for 
> git, it does not help an application like pharo read the files with long 
> paths ... without additional work ... and even then it's not clear that it 
> truly fixes the problem ... because the fundamental limit is embedded in the 
> OS ... for example from the git bash shell, I cannot `rm` the directories 
> that have long paths (I have to use the explorer to delete them) and when I 
> write out a package with long paths from Pharo3.0 the long path files are 
> silently deleted ... 
> 
> If it worked for you, that's good ... my experience was not quite as nice:)
> 
> Dale

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[p...@highoctane.be]

Yes, about the git config core.longpaths true: works here as well.

It requires git for windows > 1.9 to work. My 1.8.x choked, had to upgrade.

I have checked out the VM code where there was the GeniePlugin problem and
the issue was gone with that setup.

cp -r or rm -rf indeed give trouble.

If we used the Windows subst command to map a drive to some depth in the
path and work from there, it would solve the issue. That's how I've done
that for Java never ending directories in the past.

Operations are also very slow compared to Unix.

Phil




On Wed, Sep 30, 2015 at 6:47 PM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

>
>
> On 09/29/2015 01:50 AM, Henrik Johansen wrote:
>
>
> On 29 Sep 2015, at 1:48 , Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
>
> The big issue for git and windows (in general) is that there is a 255
> character limit on the paths for files  I recently pruned some file
> names for Metacello (on a win-hack branch) just to get Metacello to work
> with filetree ..
>
> Working with Github Desktop[1] for Windows makes the experience of using
> git from the command line tolerable on Windows - you get a retty nice bash
> shell to work with so as a non-windows user I can work in a pretty familiar
> environment ...
>
> At the moment I'm working with Pharo3.0 on Windows, so I don't have any
> useful feedback right now (assuming things have changed a bit on Windows
> with Pharo4.0 and Pharo5.0) ...
>
> Dale
>
>
> IIRC, there is some flag you can set to make (some?) the actual git client
> (but not bundled tools)  support long filenames on Windows:
> git config core.longpaths true
> For instance, cloning the PharoVM repo choked (or rather, failed
> semi-silently) on some really long selector in an obscure plugin somewhere
> until I found that...
>
>
> Thanks Henry, I have done the `git config core.longpaths true` and I
> believe that that (supposedly) addresses manipulating long file paths
> problem for git, it does not help an application like pharo read the files
> with long paths ... without additional work ... and even then it's not
> clear that it truly fixes the problem ... because the fundamental limit is
> embedded in the OS ... for example from the git bash shell, I cannot `rm`
> the directories that have long paths (I have to use the explorer to delete
> them) and when I write out a package with long paths from Pharo3.0 the long
> path files are silently deleted ...
>
> If it worked for you, that's good ... my experience was not quite as nice:)
>
> Dale
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Dale Henrichs]

1. the original code from Otto put each method in a file
2. I liked the idea of using git to manage method versions - and it is a 
really cool
feature as git is able to maintain the history of a method (file) 
as the method is

moved from class to class
3. Using directory structure actually enhanced the ability to create a 
cross-platform
scheme, since directory structure parsing is easier than coming to 
an agreement

on a common "fileout" format

With that said, assuming that a common fileout format can be agreed upon 
...

there's no reason that a file per package or file per class format could be
invented ... If you or anyone else has the time to create such a beast 
then I say go for it ...


Given that we have a functional disk representation in hand, I don't 
think that searching for a new format (that will have it's own flaws) is 
a top priority ... regardless of what the disk format looks like there 
is a real void when it comes to the tool set 


Finally the smalltalk community is not the only group that has trouble 
using git on windows because of the file path limitation ... so these 
guys that do file per package still run into trouble when using git on 
windows:)


Dale

On 9/30/15 11:57 AM, Alexandre Bergel wrote:
Why not having just one  folder level? As we would have in any other 
language? One folder per package, and inside a .st file per class.


Alexandre

Le 30 sept. 2015 à 18:47, Dale Henrichs 
> a écrit :

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Jan Vrany]

On Mon, 2015-09-28 at 16:48 -0700, Dale Henrichs wrote:
> The big issue for git and windows (in general) is that there is a 255
> character limit on the paths for files  I recently pruned some
> file names for Metacello (on a win-hack branch) just to get Metacello
> to work with filetree .. 

The limit is actually 260 characters. Not that it helps much :-)
However, there's a way (well, hack) to overcome this limit 
using special UNC pathnames like 
\\?\C:\very\long\path\here or \\?\UNC\server\share\very\long\path.

The "only" issue is that not all tools in the chain are using 
this hack...

Jan

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Jigyasa Grover]

Agreed.

On Sun, Sep 27, 2015 at 3:27 PM, 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
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Dale Henrichs]

On 09/29/2015 01:50 AM, Henrik Johansen wrote:


On 29 Sep 2015, at 1:48 , Dale Henrichs 
> wrote:


The big issue for git and windows (in general) is that there is a 255 
character limit on the paths for files  I recently pruned some 
file names for Metacello (on a win-hack branch) just to get Metacello 
to work with filetree ..


Working with Github Desktop[1] for Windows makes the experience of 
using git from the command line tolerable on Windows - you get a 
retty nice bash shell to work with so as a non-windows user I can 
work in a pretty familiar environment ...


At the moment I'm working with Pharo3.0 on Windows, so I don't have 
any useful feedback right now (assuming things have changed a bit on 
Windows with Pharo4.0 and Pharo5.0) ...


Dale


IIRC, there is some flag you can set to make (some?) the actual git 
client (but not bundled tools)  support long filenames on Windows:

git config core.longpaths true
For instance, cloning the PharoVM repo choked (or rather, failed 
semi-silently) on some really long selector in an obscure plugin 
somewhere until I found that...




Thanks Henry, I have done the `git config core.longpaths true` and I 
believe that that (supposedly) addresses manipulating long file paths 
problem for git, it does not help an application like pharo read the 
files with long paths ... without additional work ... and even then it's 
not clear that it truly fixes the problem ... because the fundamental 
limit is embedded in the OS ... for example from the git bash shell, I 
cannot `rm` the directories that have long paths (I have to use the 
explorer to delete them) and when I write out a package with long paths 
from Pharo3.0 the long path files are silently deleted ...


If it worked for you, that's good ... my experience was not quite as nice:)

Dale

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Esteban Lorenzano]

> On 29 Sep 2015, at 01:13, Ferlicot D. Cyril  wrote:
> 
> Le 28/09/2015 23:54, Levente Uzonyi a écrit :
>> 
>> If there are so many windows users, then how can it be that none of them
>> managed to explain what the actual problem with stdio handling is. I had
>> asked about the problem a while ago, but I still haven't got an answer:
>> http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 .
>> 
>> Levente
>> 
> 
> The problem is that gitfiletree use OSProcess and OSProcess use Stdio to
> get the state or the exit value of a command for example.
> But in Windows Stdio is just an ugly hack. It doesn't use the stdio but
> create 3 files (stdin, stderr' stdout) in the working directory and
> write/read this files. But as Windows doesn't use that we can't
> communicate with the system.

ah yes, I remember when I made that :)
it was for been able to run CI on windows… and I remember I told Christophe 
“let’s do this crap until we find a real solution”. 
That was like 4yrs ago :P

So, I still does not have a real solution because GetStdHandle funtion in 
windows does not work for non console apps. 
Maybe we could solve this redirecting the outputs (SetStdHandle)? 
I’m not a windows user and I don’t really know deeply this stuff, but I’d 
gladly accept any contribution to fix this issue (or at least to fix OSProcess).

Esteban 

> 
> I tried to have some look at it but I don't even know if it is a vm or
> an image problem. Some says that the dll for that is wrong, some says
> that this is an image problem. I don't have the knowledge and the time
> to go deeper on that problem.
> 
> So in order to fix a lot of problem on windows we need to fix the Stdio
> but we need someone who have the time and the knowledge and we do not
> have a lot of developers that can manage stdio on windows even if we
> have users.
> 
> -- 
> Cheers
> Cyril
> 

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Thierry Goubier]

2015-09-29 9:39 GMT+02:00 Nicolai Hess :

>
>
> 2015-09-29 7:05 GMT+02:00 Thierry Goubier :
>
>> Hi Levente,
>>
>> Le 28/09/2015 23:54, Levente Uzonyi a écrit :
>>
>>> On Sun, 27 Sep 2015, Ferlicot D. Cyril wrote:
>>>
>>> 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.

>>>
>>> If there are so many windows users, then how can it be that none of them
>>> managed to explain what the actual problem with stdio handling is. I had
>>> asked about the problem a while ago, but I still haven't got an answer:
>>> http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 .
>>>
>>
>> Well, I changed the code using ProcessWrapper with your suggestions
>> following that exchange, but my code stay fairly naive [1] (and would need
>> to run under debug), and I didn't have someone testing on Windows.
>>
>
> Can you give me an example on how to test this
>

Yes! Thanks!

Can you run a makefile under Windows? I can prepare one which calls and
loads everything to run the tests for gitfiletree.

Or just trying to load something like SmaCC from github...

Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main';
configurationOf: 'GitFileTree'; loadDevelopment

Metacello new baseline: 'SmaCC'; repository: 'gitfiletree://
github.com/ThierryGoubier/SmaCC?protocol=https'; load

If you manage to get through the SmaCC loading without a crash or a lockup,
then it means it nearly certainly works.

Thierry


>
>
>>
>> Am I writing that code correctly? If you see the equivalent code using
>> OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) on
>> the external commands framework, I am prepared to work very closely with
>> that layer including inside the vm plugin code (and David T Lewis helped me
>> a lot to fix random lockups we had).
>>
>> Thierry
>>
>> (*) Running the gitfiletree integration tests launches probably over a
>> hundred external commands in quick succession.
>>
>> [1]
>> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWrapperGitCommand.in..st
>>
>> [2]
>> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessGitCommand.in..st
>>
>>
>>> Levente
>>>
>>>
>>
>>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Nicolai Hess]

2015-09-29 14:02 GMT+02:00 Nicolai Hess :

>
>
> 2015-09-29 10:14 GMT+02:00 Thierry Goubier :
>
>>
>> Yes! Thanks!
>>
>> Can you run a makefile under Windows? I can prepare one which calls and
>> loads everything to run the tests for gitfiletree.
>>
>> Or just trying to load something like SmaCC from github...
>>
>> Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main';
>> configurationOf: 'GitFileTree'; loadDevelopment
>>
>> Metacello new baseline: 'SmaCC'; repository: 'gitfiletree://
>> github.com/ThierryGoubier/SmaCC?protocol=https'; load
>>
>> If you manage to get through the SmaCC loading without a crash or a
>> lockup, then it means it nearly certainly works.
>>
>
>
> No, it does not work, in MCFileTreeGitRepository
> class>>#runProcessWrapperGitCommand:in:
> ...
>
>
> (Smalltalk
> at: #ProcessWrapper
> ifAbsent: [ self error: 'Please load ProcessWrapper' ])
> ifNotNil:
> [ :pW |
> | command |
> command := pW new
> useStdout;
> useStderr;
> startWithCommand:
> self gitCommand , ' -C "'
> ,
> (MCFileTreeFileUtils current
> directoryPathString: aDirectory)
> , '" ' , aCommandString.
> r := command upToEnd.
> "---  MNU False>>upToEnd"
> ...
>
> somehow, the command is a boolean false, instead of a ProcessWrapper.
>
>
1. git has to be on the path
2. windows does not understand /usr/bin/git
3. changing the above to

(Smalltalk
at: #ProcessWrapper
ifAbsent: [ self error: 'Please load ProcessWrapper' ])
ifNotNil:
[ :pW |
| command |
command := pW new
useStdout;
useStderr;
startWithCommand:(
self gitCommand , ' -C "'
,
(MCFileTreeFileUtils current
directoryPathString: aDirectory)
, '" ' , aCommandString)
 yourself.
r := command upToEnd.

makes it loading the git repository, but crashes afterwards.

(with latest vm, I 'll try again with stable vm)



>
>
>
>>
>> Thierry
>>
>>
>>>
>>>

 Am I writing that code correctly? If you see the equivalent code using
 OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) on
 the external commands framework, I am prepared to work very closely with
 that layer including inside the vm plugin code (and David T Lewis helped me
 a lot to fix random lockups we had).

 Thierry

 (*) Running the gitfiletree integration tests launches probably over a
 hundred external commands in quick succession.

 [1]
 https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWrapperGitCommand.in..st

 [2]
 https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessGitCommand.in..st


> Levente
>
>


>>>
>>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Nicolai Hess]

2015-09-29 14:27 GMT+02:00 Nicolai Hess :

>
>
> 2015-09-29 14:02 GMT+02:00 Nicolai Hess :
>
>>
>>
>> 2015-09-29 10:14 GMT+02:00 Thierry Goubier :
>>
>>>
>>> Yes! Thanks!
>>>
>>> Can you run a makefile under Windows? I can prepare one which calls and
>>> loads everything to run the tests for gitfiletree.
>>>
>>> Or just trying to load something like SmaCC from github...
>>>
>>> Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main';
>>> configurationOf: 'GitFileTree'; loadDevelopment
>>>
>>> Metacello new baseline: 'SmaCC'; repository: 'gitfiletree://
>>> github.com/ThierryGoubier/SmaCC?protocol=https'; load
>>>
>>> If you manage to get through the SmaCC loading without a crash or a
>>> lockup, then it means it nearly certainly works.
>>>
>>
>>
>> No, it does not work, in MCFileTreeGitRepository
>> class>>#runProcessWrapperGitCommand:in:
>> ...
>>
>>
>> (Smalltalk
>> at: #ProcessWrapper
>> ifAbsent: [ self error: 'Please load ProcessWrapper' ])
>> ifNotNil:
>> [ :pW |
>> | command |
>> command := pW new
>> useStdout;
>> useStderr;
>> startWithCommand:
>> self gitCommand , ' -C "'
>> ,
>> (MCFileTreeFileUtils current
>> directoryPathString: aDirectory)
>> , '" ' , aCommandString.
>> r := command upToEnd.
>> "---  MNU False>>upToEnd"
>> ...
>>
>> somehow, the command is a boolean false, instead of a ProcessWrapper.
>>
>>
> 1. git has to be on the path
> 2. windows does not understand /usr/bin/git
> 3. changing the above to
>
> (Smalltalk
> at: #ProcessWrapper
> ifAbsent: [ self error: 'Please load ProcessWrapper' ])
> ifNotNil:
> [ :pW |
> | command |
> command := pW new
> useStdout;
> useStderr;
> startWithCommand:(
> self gitCommand , ' -C "'
> ,
> (MCFileTreeFileUtils current
> directoryPathString: aDirectory)
> , '" ' , aCommandString)
>  yourself.
> r := command upToEnd.
>
> makes it loading the git repository, but crashes afterwards.
>
> (with latest vm, I 'll try again with stable vm)
>
>
>

still crashes, happens on calling #exitCode



>
>>
>>
>>>
>>> Thierry
>>>
>>>


>
> Am I writing that code correctly? If you see the equivalent code using
> OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) on
> the external commands framework, I am prepared to work very closely with
> that layer including inside the vm plugin code (and David T Lewis helped 
> me
> a lot to fix random lockups we had).
>
> Thierry
>
> (*) Running the gitfiletree integration tests launches probably over a
> hundred external commands in quick succession.
>
> [1]
> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWrapperGitCommand.in..st
>
> [2]
> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessGitCommand.in..st
>
>
>> Levente
>>
>>
>
>

>>>
>>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Nicolai Hess]

2015-09-29 14:38 GMT+02:00 Thierry Goubier :

>
> 2015-09-29 14:34 GMT+02:00 Nicolai Hess :
>
>>
>>
>> 2015-09-29 14:27 GMT+02:00 Nicolai Hess :
>>
>>>
>>>
>>> 2015-09-29 14:02 GMT+02:00 Nicolai Hess :
>>>


 2015-09-29 10:14 GMT+02:00 Thierry Goubier :

>
> Yes! Thanks!
>
> Can you run a makefile under Windows? I can prepare one which calls
> and loads everything to run the tests for gitfiletree.
>
> Or just trying to load something like SmaCC from github...
>
> Gofer new url: '
> http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main';
> configurationOf: 'GitFileTree'; loadDevelopment
>
> Metacello new baseline: 'SmaCC'; repository: 'gitfiletree://
> github.com/ThierryGoubier/SmaCC?protocol=https'; load
>
> If you manage to get through the SmaCC loading without a crash or a
> lockup, then it means it nearly certainly works.
>


 No, it does not work, in MCFileTreeGitRepository
 class>>#runProcessWrapperGitCommand:in:
 ...


 (Smalltalk
 at: #ProcessWrapper
 ifAbsent: [ self error: 'Please load ProcessWrapper' ])
 ifNotNil:
 [ :pW |
 | command |
 command := pW new
 useStdout;
 useStderr;
 startWithCommand:
 self gitCommand , ' -C "'
 ,
 (MCFileTreeFileUtils current
 directoryPathString: aDirectory)
 , '" ' , aCommandString.
 r := command upToEnd.
 "---  MNU False>>upToEnd"
 ...

 somehow, the command is a boolean false, instead of a ProcessWrapper.


>>> 1. git has to be on the path
>>> 2. windows does not understand /usr/bin/git
>>> 3. changing the above to
>>>
>>> (Smalltalk
>>> at: #ProcessWrapper
>>> ifAbsent: [ self error: 'Please load ProcessWrapper' ])
>>> ifNotNil:
>>> [ :pW |
>>> | command |
>>> command := pW new
>>> useStdout;
>>> useStderr;
>>> startWithCommand:(
>>> self gitCommand , ' -C "'
>>> ,
>>> (MCFileTreeFileUtils current
>>> directoryPathString: aDirectory)
>>> , '" ' , aCommandString)
>>>  yourself.
>>> r := command upToEnd.
>>>
>>> makes it loading the git repository, but crashes afterwards.
>>>
>>> (with latest vm, I 'll try again with stable vm)
>>>
>>>
>>>
>>
>> still crashes, happens on calling #exitCode
>>
>
> It's a crash instead of a DNU, on the line ?
>
> command exitCode > 0
> ifTrue:
>
> Thierry
>

Yes, a crash.
I am not sure, I tried to remove the call to #exitCode
but it still crashes
I tried to debug the vm, but now it does not crash.

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Thierry Goubier]

2015-09-29 14:27 GMT+02:00 Nicolai Hess :

>
>
> 2015-09-29 14:02 GMT+02:00 Nicolai Hess :
>
>>
>>
>> 2015-09-29 10:14 GMT+02:00 Thierry Goubier :
>>
>>>
>>> Yes! Thanks!
>>>
>>> Can you run a makefile under Windows? I can prepare one which calls and
>>> loads everything to run the tests for gitfiletree.
>>>
>>> Or just trying to load something like SmaCC from github...
>>>
>>> Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main';
>>> configurationOf: 'GitFileTree'; loadDevelopment
>>>
>>> Metacello new baseline: 'SmaCC'; repository: 'gitfiletree://
>>> github.com/ThierryGoubier/SmaCC?protocol=https'; load
>>>
>>> If you manage to get through the SmaCC loading without a crash or a
>>> lockup, then it means it nearly certainly works.
>>>
>>
>>
>> No, it does not work, in MCFileTreeGitRepository
>> class>>#runProcessWrapperGitCommand:in:
>> ...
>>
>>
>> (Smalltalk
>> at: #ProcessWrapper
>> ifAbsent: [ self error: 'Please load ProcessWrapper' ])
>> ifNotNil:
>> [ :pW |
>> | command |
>> command := pW new
>> useStdout;
>> useStderr;
>> startWithCommand:
>> self gitCommand , ' -C "'
>> ,
>> (MCFileTreeFileUtils current
>> directoryPathString: aDirectory)
>> , '" ' , aCommandString.
>> r := command upToEnd.
>> "---  MNU False>>upToEnd"
>> ...
>>
>> somehow, the command is a boolean false, instead of a ProcessWrapper.
>>
>>
> 1. git has to be on the path
> 2. windows does not understand /usr/bin/git
>

Ok, can you give me an example path for git on a windows system?


> 3. changing the above to
>
> (Smalltalk
> at: #ProcessWrapper
> ifAbsent: [ self error: 'Please load ProcessWrapper' ])
> ifNotNil:
> [ :pW |
> | command |
> command := pW new
> useStdout;
> useStderr;
> startWithCommand:(
> self gitCommand , ' -C "'
> ,
> (MCFileTreeFileUtils current
> directoryPathString: aDirectory)
> , '" ' , aCommandString)
>  yourself.
> r := command upToEnd.
>
> makes it loading the git repository, but crashes afterwards.
>

What is the crash like? Inside Pharo or vm crash?

Thierry


>
> (with latest vm, I 'll try again with stable vm)
>
>
>
>>
>>
>>
>>>
>>> Thierry
>>>
>>>


>
> Am I writing that code correctly? If you see the equivalent code using
> OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) on
> the external commands framework, I am prepared to work very closely with
> that layer including inside the vm plugin code (and David T Lewis helped 
> me
> a lot to fix random lockups we had).
>
> Thierry
>
> (*) Running the gitfiletree integration tests launches probably over a
> hundred external commands in quick succession.
>
> [1]
> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWrapperGitCommand.in..st
>
> [2]
> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessGitCommand.in..st
>
>
>> Levente
>>
>>
>
>

>>>
>>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Thierry Goubier]

2015-09-29 14:34 GMT+02:00 Nicolai Hess :

>
>
> 2015-09-29 14:27 GMT+02:00 Nicolai Hess :
>
>>
>>
>> 2015-09-29 14:02 GMT+02:00 Nicolai Hess :
>>
>>>
>>>
>>> 2015-09-29 10:14 GMT+02:00 Thierry Goubier :
>>>

 Yes! Thanks!

 Can you run a makefile under Windows? I can prepare one which calls and
 loads everything to run the tests for gitfiletree.

 Or just trying to load something like SmaCC from github...

 Gofer new url: '
 http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main';
 configurationOf: 'GitFileTree'; loadDevelopment

 Metacello new baseline: 'SmaCC'; repository: 'gitfiletree://
 github.com/ThierryGoubier/SmaCC?protocol=https'; load

 If you manage to get through the SmaCC loading without a crash or a
 lockup, then it means it nearly certainly works.

>>>
>>>
>>> No, it does not work, in MCFileTreeGitRepository
>>> class>>#runProcessWrapperGitCommand:in:
>>> ...
>>>
>>>
>>> (Smalltalk
>>> at: #ProcessWrapper
>>> ifAbsent: [ self error: 'Please load ProcessWrapper' ])
>>> ifNotNil:
>>> [ :pW |
>>> | command |
>>> command := pW new
>>> useStdout;
>>> useStderr;
>>> startWithCommand:
>>> self gitCommand , ' -C "'
>>> ,
>>> (MCFileTreeFileUtils current
>>> directoryPathString: aDirectory)
>>> , '" ' , aCommandString.
>>> r := command upToEnd.
>>> "---  MNU False>>upToEnd"
>>> ...
>>>
>>> somehow, the command is a boolean false, instead of a ProcessWrapper.
>>>
>>>
>> 1. git has to be on the path
>> 2. windows does not understand /usr/bin/git
>> 3. changing the above to
>>
>> (Smalltalk
>> at: #ProcessWrapper
>> ifAbsent: [ self error: 'Please load ProcessWrapper' ])
>> ifNotNil:
>> [ :pW |
>> | command |
>> command := pW new
>> useStdout;
>> useStderr;
>> startWithCommand:(
>> self gitCommand , ' -C "'
>> ,
>> (MCFileTreeFileUtils current
>> directoryPathString: aDirectory)
>> , '" ' , aCommandString)
>>  yourself.
>> r := command upToEnd.
>>
>> makes it loading the git repository, but crashes afterwards.
>>
>> (with latest vm, I 'll try again with stable vm)
>>
>>
>>
>
> still crashes, happens on calling #exitCode
>

It's a crash instead of a DNU, on the line ?

command exitCode > 0
ifTrue:

Thierry

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Levente Uzonyi]

On Tue, 29 Sep 2015, Nicolai Hess wrote:




2015-09-29 14:27 GMT+02:00 Nicolai Hess :


  2015-09-29 14:02 GMT+02:00 Nicolai Hess :


2015-09-29 10:14 GMT+02:00 Thierry Goubier 
:

Yes! Thanks!

Can you run a makefile under Windows? I can prepare one which calls and loads 
everything to run the tests for gitfiletree.

Or just trying to load something like SmaCC from github...

Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main'; 
configurationOf: 'GitFileTree'; loadDevelopment

Metacello new baseline: 'SmaCC'; repository: 
'gitfiletree://github.com/ThierryGoubier/SmaCC?protocol=https'; load

If you manage to get through the SmaCC loading without a crash or a lockup, 
then it means it nearly certainly works.



No, it does not work, in MCFileTreeGitRepository 
class>>#runProcessWrapperGitCommand:in:
...


(Smalltalk
        at: #ProcessWrapper
        ifAbsent: [ self error: 'Please load ProcessWrapper' ])
        ifNotNil:
            [ :pW |
            | command |
            command := pW new
                useStdout;
                useStderr;
                startWithCommand:
                    self gitCommand , ' -C "'
                        ,
                            (MCFileTreeFileUtils current directoryPathString: 
aDirectory)
                        , '" ' , aCommandString.
            r := command upToEnd.    
"---  MNU False>>upToEnd"
...

somehow, the command is a boolean false, instead of a ProcessWrapper.


1. git has to be on the path
2. windows does not understand /usr/bin/git
3. changing the above to

(Smalltalk
        at: #ProcessWrapper
        ifAbsent: [ self error: 'Please load ProcessWrapper' ])
        ifNotNil:
            [ :pW |
            | command |
            command := pW new
                useStdout;
                useStderr;
                startWithCommand:(
                    self gitCommand , ' -C "'
                        ,
                            (MCFileTreeFileUtils current directoryPathString: 
aDirectory)
                        , '" ' , aCommandString)


There's a semicolon missing from the end of the line.


 yourself.
            r := command upToEnd.

makes it loading the git repository, but crashes afterwards.

(with latest vm, I 'll try again with stable vm)

 


still crashes, happens on calling #exitCode


Does #isRunning return true when #exitCode is called? If so, the crash is 
to be expected - aka it's a known issue. This is because one must not 
request for the exit code, by sending #exitCode, before the process has 
terminated.


If it keeps crashing, then you should consider enabling the plugin's log 
to see what's happening.


Levente



 

 

Thierry
 
 

  Am I writing that code correctly? If you see the equivalent code using 
OSProcess[2], you understand that, as
  GitFileTree is a heavy hitter(*) on the external commands framework, I am 
prepared to work very closely with
  that layer including inside the vm plugin code (and David T Lewis helped 
me a lot to fix random lockups we
  had).

  Thierry

  (*) Running the gitfiletree integration tests launches probably over a 
hundred external commands in quick
  succession.

  
[1]https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWra
  pperGitCommand.in..st

  
[2]https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessG
  itCommand.in..st


Levente

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Thierry Goubier]

2015-09-29 10:50 GMT+02:00 Henrik Johansen :

>
> On 29 Sep 2015, at 1:48 , Dale Henrichs 
> wrote:
>
> The big issue for git and windows (in general) is that there is a 255
> character limit on the paths for files  I recently pruned some file
> names for Metacello (on a win-hack branch) just to get Metacello to work
> with filetree ..
>
> Working with Github Desktop[1] for Windows makes the experience of using
> git from the command line tolerable on Windows - you get a retty nice bash
> shell to work with so as a non-windows user I can work in a pretty familiar
> environment ...
>
> At the moment I'm working with Pharo3.0 on Windows, so I don't have any
> useful feedback right now (assuming things have changed a bit on Windows
> with Pharo4.0 and Pharo5.0) ...
>
> Dale
>
>
> IIRC, there is some flag you can set to make (some?) the actual git client
> (but not bundled tools)  support long filenames on Windows:
> git config core.longpaths true
> For instance, cloning the PharoVM repo choked (or rather, failed
> semi-silently) on some really long selector in an obscure plugin somewhere
> until I found that...
>

Interesting. This could allow gitfiletree(*) to load from a repository
where filetree would fail to load... but both would fail upon writing :(

(*) gitfiletree loads packages via a call to git archive and may so avoid
some of the long paths.

Thierry


>
> Cheers,
> Henry
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Nicolai Hess]

2015-09-29 10:14 GMT+02:00 Thierry Goubier :

>
>
> 2015-09-29 9:39 GMT+02:00 Nicolai Hess :
>
>>
>>
>> 2015-09-29 7:05 GMT+02:00 Thierry Goubier :
>>
>>> Hi Levente,
>>>
>>> Le 28/09/2015 23:54, Levente Uzonyi a écrit :
>>>
 On Sun, 27 Sep 2015, Ferlicot D. Cyril wrote:

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

 If there are so many windows users, then how can it be that none of them
 managed to explain what the actual problem with stdio handling is. I had
 asked about the problem a while ago, but I still haven't got an answer:
 http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 .

>>>
>>> Well, I changed the code using ProcessWrapper with your suggestions
>>> following that exchange, but my code stay fairly naive [1] (and would need
>>> to run under debug), and I didn't have someone testing on Windows.
>>>
>>
>> Can you give me an example on how to test this
>>
>
> Yes! Thanks!
>
> Can you run a makefile under Windows? I can prepare one which calls and
> loads everything to run the tests for gitfiletree.
>
> Or just trying to load something like SmaCC from github...
>
> Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main';
> configurationOf: 'GitFileTree'; loadDevelopment
>
> Metacello new baseline: 'SmaCC'; repository: 'gitfiletree://
> github.com/ThierryGoubier/SmaCC?protocol=https'; load
>
> If you manage to get through the SmaCC loading without a crash or a
> lockup, then it means it nearly certainly works.
>


No, it does not work, in MCFileTreeGitRepository
class>>#runProcessWrapperGitCommand:in:
...


(Smalltalk
at: #ProcessWrapper
ifAbsent: [ self error: 'Please load ProcessWrapper' ])
ifNotNil:
[ :pW |
| command |
command := pW new
useStdout;
useStderr;
startWithCommand:
self gitCommand , ' -C "'
,
(MCFileTreeFileUtils current
directoryPathString: aDirectory)
, '" ' , aCommandString.
r := command upToEnd.
"---  MNU False>>upToEnd"
...

somehow, the command is a boolean false, instead of a ProcessWrapper.




>
> Thierry
>
>
>>
>>
>>>
>>> Am I writing that code correctly? If you see the equivalent code using
>>> OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) on
>>> the external commands framework, I am prepared to work very closely with
>>> that layer including inside the vm plugin code (and David T Lewis helped me
>>> a lot to fix random lockups we had).
>>>
>>> Thierry
>>>
>>> (*) Running the gitfiletree integration tests launches probably over a
>>> hundred external commands in quick succession.
>>>
>>> [1]
>>> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWrapperGitCommand.in..st
>>>
>>> [2]
>>> https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessGitCommand.in..st
>>>
>>>
 Levente


>>>
>>>
>>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Henrik Johansen]

> On 29 Sep 2015, at 1:48 , Dale Henrichs  
> wrote:
> 
> The big issue for git and windows (in general) is that there is a 255 
> character limit on the paths for files  I recently pruned some file names 
> for Metacello (on a win-hack branch) just to get Metacello to work with 
> filetree ..
> 
> Working with Github Desktop[1] for Windows makes the experience of using git 
> from the command line tolerable on Windows - you get a retty nice bash shell 
> to work with so as a non-windows user I can work in a pretty familiar 
> environment ...
> 
> At the moment I'm working with Pharo3.0 on Windows, so I don't have any 
> useful feedback right now (assuming things have changed a bit on Windows with 
> Pharo4.0 and Pharo5.0) ...
> 
> Dale

IIRC, there is some flag you can set to make (some?) the actual git client (but 
not bundled tools)  support long filenames on Windows:
git config core.longpaths true
For instance, cloning the PharoVM repo choked (or rather, failed semi-silently) 
on some really long selector in an obscure plugin somewhere until I found 
that...

Cheers,
Henry


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Thierry Goubier]

Hi Levente,

Le 28/09/2015 23:54, Levente Uzonyi a écrit :

On Sun, 27 Sep 2015, Ferlicot D. Cyril wrote:


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.


If there are so many windows users, then how can it be that none of them
managed to explain what the actual problem with stdio handling is. I had
asked about the problem a while ago, but I still haven't got an answer:
http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 .


Well, I changed the code using ProcessWrapper with your suggestions 
following that exchange, but my code stay fairly naive [1] (and would 
need to run under debug), and I didn't have someone testing on Windows.


Am I writing that code correctly? If you see the equivalent code using 
OSProcess[2], you understand that, as GitFileTree is a heavy hitter(*) 
on the external commands framework, I am prepared to work very closely 
with that layer including inside the vm plugin code (and David T Lewis 
helped me a lot to fix random lockups we had).


Thierry

(*) Running the gitfiletree integration tests launches probably over a 
hundred external commands in quick succession.


[1] 
https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runProcessWrapperGitCommand.in..st


[2] 
https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloFileTree-Git.package/MCFileTreeGitRepository.class/class/runOSProcessGitCommand.in..st




Levente

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[p...@highoctane.be]

Well, there is some kind of but I was tired and the stream broke as my
internet connection went bust.

(and I should have done the full setup). Ah these things pile up.

Still, one can see the trainwreck over here:
https://www.livecoding.tv/philippeback/videos/

Pick the things with "git" in the tile.

Phil

On Mon, Sep 28, 2015 at 10:59 AM, Damien Cassou 
wrote:

>
> philippe.b...@highoctane.be  writes:
>
> > It isn't. It is actually very easy to use git.
> >
> > Time for a video :-)
> >
> > Expect that for tomorrow.
>
> tomorrow is today :-). We expect it!
>
> Thanks Philippe
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Levente Uzonyi]

On Sun, 27 Sep 2015, Ferlicot D. Cyril wrote:


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.


If there are so many windows users, then how can it be that none of them 
managed to explain what the actual problem with stdio handling is. I had
asked about the problem a while ago, but I still haven't got an answer: 
http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 .


Levente




On Sun, Sep 27, 2015 at 12:58 PM 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






--
Cheers
Cyril

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Dale Henrichs]

On 9/27/15 11:53 PM, stepharo wrote:



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,

I have been working on this problem for several years now with tODE and 
in tODE I've been able to build a project tool that handles the mundane 
everyday, commit/checkout/branch/push/pull operations using menu items 
...  this approach means that folks can choose to use a git workflow 
that matches their whims/needs --- without having to become intimately 
familiar with the more arcane bits of git.


I did find that it is absolutely necessary to have a Smalltalk gui based 
git merge tool ... there are non-smalltalk merge tools out there, but I 
prefer to do my merges in the comfort of my Smalltalk development 
environment:) ...


Another tool that is important is what I call `skew diff` and `skew 
merge` ... `skew` happens when a git repository on disk is checked out 
to a commit that differs from the commit when the packages were loaded 
into an image (think of an image that has been sitting unused for a 
couple of months). Metacello has features for making it possible to 
record the SHA of the commit present when a project is loaded from a git 
repository and my project tool compares this SHA with the current SHA of 
the git repository and notices when SHA skew occurs ... `skew diff` and 
`skew merge` were invented to help a developer understand the 
implications and repair (if necessary) - more often than not a simple 
load (or ignoring the skew) sufficient, but it is imperative that a 
developer be notified that this skew is present ...


So, I think that Pharo-based tools can be built so that developers 
can go about there daily work without ever having to drop down to the 
git command-line (macros or no macros)...


Dale

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Max Leske]

> On 28 Sep 2015, at 04:27, Ben Coman  wrote:
> 
> On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano  
> 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.
> .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  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
>>> 
>>> 
>> 
>> 
> 

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Thierry Goubier]

2015-09-28 8:53 GMT+02:00 stepharo :

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Peter Uhnák]

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Thierry Goubier]

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[stepharo]

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Thierry Goubier]

2015-09-28 13:57 GMT+02:00 Ben Coman :

> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
>  wrote:
> > 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.
> >> .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 :(
>
> btw, would "notes" [1] be useful for attaching metadata?
>  "A typical use of notes is to supplement a commit message without
> changing the commit itself."
> Or is the metadata better inside the commit?
>

I don't know. What happens to notes when you merge? Do you need to fetch
down all the ancestors (some of them without notes, because it was a merge
of whatever external stuff was in the repository, so you need to
recurse[2]) and merge them yourself everytime? What happens if a guy do a
by hand edit of a st file and commits outside of Pharo? Can it work outside
git (Fossil, Mercury, bazaar)? Does it scale to a lot of metadata?

Thierry

[2] gitfiletree has that code, and it gives unintuitive, but correct,
results at time.



> [1] http://git-scm.com/docs/git-notes
>
> cheers -ben
>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Ben Coman]

On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
 wrote:
> 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.
>> .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 :(

btw, would "notes" [1] be useful for attaching metadata?
 "A typical use of notes is to supplement a commit message without
changing the commit itself."
Or is the metadata better inside the commit?

[1] http://git-scm.com/docs/git-notes

cheers -ben

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Stephan Eggermont]

On 28-09-15 04:27, Ben Coman wrote:


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.


There is no such thing as one workflow. That is to say, the one workflow 
is simply very complicated, as different people need to solve different 
problems with design data management. The problems of the core pharo 
team are not those of the community.


To do this well it would be good to work with personas, like in
http://gsoc2013.esug.org/projects/distributed-issue-tracker
Adoption will come only when a sufficiently large, consistent and 
complete part of the stakeholders needs is covered. Personas are also 
very useful to drive the documentation.


Stephan

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Alexandre Bergel]

Video are good. But please, do not show trivial things. Show us an example with 
several users and conflict resolution.

Alexandre


> On Sep 28, 2015, at 10:59 AM, Damien Cassou  wrote:
> 
> 
> philippe.b...@highoctane.be  writes:
> 
>> It isn't. It is actually very easy to use git.
>> 
>> Time for a video :-)
>> 
>> Expect that for tomorrow.
> 
> tomorrow is today :-). We expect it!
> 
> Thanks Philippe
> 
> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
> 

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Damien Cassou]

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Damien Cassou]

philippe.b...@highoctane.be  writes:

> It isn't. It is actually very easy to use git.
>
> Time for a video :-)
>
> Expect that for tomorrow.

tomorrow is today :-). We expect it!

Thanks Philippe

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

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Peter Uhnák]

>
> If there are so many windows users


There are many windows users,
there are NOT many windows + git users.
Probably because everyone gives up on gitfiletree after ten minutes and
switch to regular filetree.

I think that none of the developers of Git in Pharo / gitfiletree use
Windows, so some new who knows both Git and Windows well would need to come
around at look into it. Or someone new who is interested in it enough that
is willing to spend his time understanding it and then fixing it.

Peter

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Ferlicot D. Cyril]

Le 28/09/2015 23:54, Levente Uzonyi a écrit :
> 
> If there are so many windows users, then how can it be that none of them
> managed to explain what the actual problem with stdio handling is. I had
> asked about the problem a while ago, but I still haven't got an answer:
> http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 .
> 
> Levente
> 

The problem is that gitfiletree use OSProcess and OSProcess use Stdio to
get the state or the exit value of a command for example.
But in Windows Stdio is just an ugly hack. It doesn't use the stdio but
create 3 files (stdin, stderr' stdout) in the working directory and
write/read this files. But as Windows doesn't use that we can't
communicate with the system.

I tried to have some look at it but I don't even know if it is a vm or
an image problem. Some says that the dll for that is wrong, some says
that this is an image problem. I don't have the knowledge and the time
to go deeper on that problem.

So in order to fix a lot of problem on windows we need to fix the Stdio
but we need someone who have the time and the knowledge and we do not
have a lot of developers that can manage stdio on windows even if we
have users.

-- 
Cheers
Cyril



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Dale Henrichs]

The big issue for git and windows (in general) is that there is a 255 
character limit on the paths for files  I recently pruned some file 
names for Metacello (on a win-hack branch) just to get Metacello to work 
with filetree ..


Working with Github Desktop[1] for Windows makes the experience of using 
git from the command line tolerable on Windows - you get a retty nice 
bash shell to work with so as a non-windows user I can work in a pretty 
familiar environment ...


At the moment I'm working with Pharo3.0 on Windows, so I don't have any 
useful feedback right now (assuming things have changed a bit on Windows 
with Pharo4.0 and Pharo5.0) ...


Dale

[1] https://desktop.github.com/

On 09/28/2015 03:39 PM, Peter Uhnák wrote:


If there are so many windows users


There are many windows users,
there are NOT many windows + git users.
Probably because everyone gives up on gitfiletree after ten minutes 
and switch to regular filetree.


I think that none of the developers of Git in Pharo / gitfiletree use 
Windows, so some new who knows both Git and Windows well would need to 
come around at look into it. Or someone new who is interested in it 
enough that is willing to spend his time understanding it and then 
fixing it.


Peter

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Dale Henrichs]

On 09/28/2015 04:13 PM, Ferlicot D. Cyril wrote:

Le 28/09/2015 23:54, Levente Uzonyi a écrit :

If there are so many windows users, then how can it be that none of them
managed to explain what the actual problem with stdio handling is. I had
asked about the problem a while ago, but I still haven't got an answer:
http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 .

Levente


The problem is that gitfiletree use OSProcess and OSProcess use Stdio to
get the state or the exit value of a command for example.
But in Windows Stdio is just an ugly hack. It doesn't use the stdio but
create 3 files (stdin, stderr' stdout) in the working directory and
write/read this files. But as Windows doesn't use that we can't
communicate with the system.

I tried to have some look at it but I don't even know if it is a vm or
an image problem. Some says that the dll for that is wrong, some says
that this is an image problem. I don't have the knowledge and the time
to go deeper on that problem.

So in order to fix a lot of problem on windows we need to fix the Stdio
but we need someone who have the time and the knowledge and we do not
have a lot of developers that can manage stdio on windows even if we
have users.
+1 ... yeah the stderr is not fun ... I did add some bash error traps 
(see my other message about using Git Bash on windows as part of GitHub 
Desktop for Windows) so that I could at least arrange to have stderr 
dumped to stdout on an error ...


Dale

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Levente Uzonyi]

On Tue, 29 Sep 2015, Ferlicot D. Cyril wrote:


Le 28/09/2015 23:54, Levente Uzonyi a écrit :


If there are so many windows users, then how can it be that none of them
managed to explain what the actual problem with stdio handling is. I had
asked about the problem a while ago, but I still haven't got an answer:
http://forum.world.st/Google-Code-Shutdown-tt4814760.html#a4840937 .

Levente



The problem is that gitfiletree use OSProcess and OSProcess use Stdio to
get the state or the exit value of a command for example.


If you check the message I linked, it says GitFileTree uses ProcessWrapper 
instead of OSProcess on Windows.



But in Windows Stdio is just an ugly hack. It doesn't use the stdio but
create 3 files (stdin, stderr' stdout) in the working directory and
write/read this files. But as Windows doesn't use that we can't
communicate with the system.


ProcessWrapper allows you to access the three streams from the image 
without creating files.


Levente



I tried to have some look at it but I don't even know if it is a vm or
an image problem. Some says that the dll for that is wrong, some says
that this is an image problem. I don't have the knowledge and the time
to go deeper on that problem.

So in order to fix a lot of problem on windows we need to fix the Stdio
but we need someone who have the time and the knowledge and we do not
have a lot of developers that can manage stdio on windows even if we
have users.

--
Cheers
Cyril

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Christophe Demarey]

Le 28 sept. 2015 à 13:57, Ben Coman a écrit :

> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
>  wrote:
>> 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.
>>> .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 :(
> 
> btw, would "notes" [1] be useful for attaching metadata?
> "A typical use of notes is to supplement a commit message without
> changing the commit itself."
> Or is the metadata better inside the commit?
> 
> [1] http://git-scm.com/docs/git-notes

I would not use that to store data useful to Pharo.
Packages meta-data should be versioned at the same place that the code itself.

Git is the trendy SCM but there are others. I prefer to not rely on a specific 
feature of a SCM to let door opened to others

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Ben Coman]

On Mon, Sep 28, 2015 at 8:06 PM, Thierry Goubier
 wrote:
>
>
> 2015-09-28 13:57 GMT+02:00 Ben Coman :
>>
>> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
>>  wrote:
>> > 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.
>> >> .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 :(
>>
>> btw, would "notes" [1] be useful for attaching metadata?
>>  "A typical use of notes is to supplement a commit message without
>> changing the commit itself."
>> Or is the metadata better inside the commit?
>
>
> I don't know. What happens to notes when you merge? Do you need to fetch
> down all the ancestors (some of them without notes, because it was a merge
> of whatever external stuff was in the repository, so you need to recurse[2])
> and merge them yourself everytime? What happens if a guy do a by hand edit
> of a st file and commits outside of Pharo? Can it work outside git (Fossil,
> Mercury, bazaar)? Does it scale to a lot of metadata?
>
> Thierry
>
> [2] gitfiletree has that code, and it gives unintuitive, but correct,
> results at time.
>
>
>>
>> [1] http://git-scm.com/docs/git-notes
>>

All good questions I don't have answers for.  Its something I only
came across last week and I'm still understanding its general usage
pattern.
cheers -ben

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Max Leske]

> On 28 Sep 2015, at 13:57, Ben Coman  wrote:
> 
> On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier
>  wrote:
>> 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.
>>> .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 :(
> 
> btw, would "notes" [1] be useful for attaching metadata?
> "A typical use of notes is to supplement a commit message without
> changing the commit itself."
> Or is the metadata better inside the commit?

Yes it could. I’ve been thinking about that too. There are some nice 
properties, e.g. 1 commit <-> one note (where a note can be tree). That way you 
don’t get merge conflicts on changing metadata.
However, you’d need to find an equivalent mechanism for each new SCM. Also, 
using such a mechanism is a bit obscure. But the idea definitely deserves some 
attention.

Cheers,
Max

> 
> [1] http://git-scm.com/docs/git-notes
> 
> cheers -ben
> 

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Thierry Goubier]

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Esteban Lorenzano]

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Peter Uhnák]

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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[stepharo]

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

Re: [Pharo-dev] 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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Ben Coman]

On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano  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.
.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  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
>>
>>
>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[philippe.b...@highoctane.be]

Le 28 sept. 2015 04:29, "Ben Coman"  a écrit :
>
> On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano 
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.
> .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  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
> >>
> >>
> >
> >
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Volkert]

+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

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Dimitris Chloupis]

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 
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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Alexandre Bergel]

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  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  
> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[philippe.b...@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"  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 
> 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 <
> alexandre.ber...@me.com> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Dimitris Chloupis]

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 
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 
> 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 <
> alexandre.ber...@me.com> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] If all Pharo projects were on GitHub...

[Ferlicot D. Cyril]

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
> > 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
Description: OpenPGP digital signature