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 <kilon.alios@gmail.com> 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.bergel@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

philippe.back@highoctane.be <philippe.back@gmail.com> 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

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 <damien.cassou@inria.fr> wrote:

philippe.back@highoctane.be <philippe.back@gmail.com> 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 <alexandre.bergel@me.com> 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

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

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

-- Cheers Cyril

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

2015-09-29 10:50 GMT+02:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:

On 29 Sep 2015, at 1:48 , Dale Henrichs <dale.henrichs@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...

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

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.henrichs@gemtalksystems.com> wrote:

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

On 29 Sep 2015, at 1:48 , Dale Henrichs < <dale.henrichs@gemtalksystems.com>dale.henrichs@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

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 <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> a écrit :

Le 1 oct. 2015 13:21, "Damien Cassou" <damien.cassou@inria.fr> a écrit :

Alexandre Bergel <alexandre.bergel@me.com> 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

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

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

2015-10-01 6:33 GMT+02:00 Jan Vrany <jan.vrany@fit.cvut.cz <mailto:jan.vrany@fit.cvut.cz>>:

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

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

On 29 Sep 2015, at 01:13, Ferlicot D. Cyril <cyril.ferlicot@gmail.com> 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

2015-09-29 7:05 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

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

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

[2] https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloF...

...

Levente

2015-09-29 10:14 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

2015-09-29 9:39 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

...

2015-09-29 7:05 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

...

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

[2] https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloF...

...

Levente

2015-09-29 14:27 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

2015-09-29 14:02 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

...

2015-09-29 10:14 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

...

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

[2] https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloF...

...

Levente

2015-09-29 14:34 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

2015-09-29 14:27 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

...

2015-09-29 14:02 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

...

2015-09-29 10:14 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

...

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

On Tue, 29 Sep 2015, Nicolai Hess wrote:

2015-09-29 14:27 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

2015-09-29 14:02 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

2015-09-29 10:14 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

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/MonticelloF... pperGitCommand.in..st

[2]https://github.com/dalehenrich/filetree/blob/pharo5.0/repository/MonticelloF... itCommand.in..st

Levente

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 <stepharo@free.fr> 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

Le 28 sept. 2015 04:29, "Ben Coman" <btc@openinworld.com> a écrit :

On Sun, Sep 27, 2015 at 8:59 PM, Esteban Lorenzano <estebanlm@gmail.com>

wrote:

...

Hi,

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

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

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

Would moving to libgit2 bypass the problem with stdio?

...

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

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

...

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

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

cheers, Esteban

...

On 27 Sep 2015, at 13:43, stepharo <stepharo@free.fr> 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

Le 28/09/2015 04:27, Ben Coman a écrit :

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

Hum, I thought that as well, but in fact write the merge driver turned out as far better and simpler. Moreover, all type of data oriented files (ston, json, version) do not merge properly in git. So even Esteban saying he will use STON does not seems to solve the merge issue, unless he is planning something else. I do take in account we will have more metadata in the future, thanks to EPICEA, so we need a way to handle it. Merging is easy, you just need to hook into it. I believed also that we could do the merge ourselves and force git to commit the result, but discovered this was a bad idea. Imagine having to fire Pharo to merge a 250k OCaml project with 2k of st code in it :(

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

Unless you have some experience of Monticello, Metacello, the Pharo workflow, some of the workflow outside Pharo, and git, then defining this workflow is shooting in the dark. So, first attempts are either: - be flexible, so that you fit into a pre-existing workflow, and explore options, - be dictatorial in your shot in the dark, and pray you got it right. Now, we've solved all the hard points (apart from the Windows support), so we can imagine a future. Thierry

2015-09-28 13:57 GMT+02:00 Ben Coman <btc@openinworld.com>:

On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier <thierry.goubier@gmail.com> 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. NNNN.metadata, and Monticello knows to pick up the highest numbered metadata.

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

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

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

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

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

On Mon, Sep 28, 2015 at 2:43 PM, Thierry Goubier <thierry.goubier@gmail.com> 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. NNNN.metadata, and Monticello knows to pick up the highest numbered metadata.

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

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

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

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

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

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

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