Hi Kilon, 2016-11-07 9:57 GMT+01:00 Dimitris Chloupis <kilon.al...@gmail.com>:
> > Git requirements is basically non existent, it mainly works with text > files and with less support for binary files. Pharo does not need anything > but text files to be ready for Git. We had text files since forever with > fileouts and became more convenient with filetree. > Agreed (of course!). > > You are also wrong about Seaside kind of projects. Its actually ironic to > talk about complex projects when Git itself was made by the creator of > Linux and the Linux kernel developers have been using it for the Linux > kernel for ages. Actually one of the reasons why Linux created Git was > because he was disappointed how slow and cumbersome SVN was with big and > complex projects and to this day Git's speed and ability to handle enormous > complexity with ease is what makes it first choice for many projects and > probably the most popular VCS. > > Aa such not only SmalltalkHub has been an extremely poor alternativre to > Github , its claims like yours that keep the Pharo community using tools > that extremely limited , buggy and close to nowhere as Smalltalky enough. I > am not talking about here just for Smalltalkhub but also Monticello. That > weird Gui thing , that is just weird and sometimes is also weird. > > If however here we talk personal taste, if people want to recreate tools > that exist outside the pharo image because they prefer to stay inside the > pharo image , I am not against that but then I never criticised personal > taste. Its a free world after all. Tools like Iceberg are more than > welcomed as long as I can easily remove them from my image. > > Personally the only toolset I will be implementing will be a tool to > completely bypass monticello and filetree and instead mark classes for > export and code will be exported most likely in a fileout format > automatically each time I hit accept in the browser. > > Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me (Jan's format is even more conflict-oriented than Filetree metadata, but it is a design goal). Cuis git repository is a mess to me; very hard to build a coherent 'rebuild a new Cuis here' process on it like I routinely do on Pharo. I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement. (I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991) Regards, Thierry
