Iceberg https://github.com/pharo-vcs/iceberg is the Git/etc. integration built into Pharo and works extremely well. You don't need to "file out" code if that's what you meant.
Same as other Smalltalk implementations — VM + .image file & .sources file & .changes file.
.image is a snapshot/cache
.changes is recovery log text of what has been done with the .image file
.sources is source code text for the .image smapshot
I don't know how Pharo does it but I could see that every class had its own source-file, committed to git ?
Think of it as version controlling a package of class definitions.
The whole idea with Smalltalk and Pharo is that you don't have files.
You have class definitions, and these are only version controlled in text files as a concession to the extreme populatity of GitHub.
The answer is that each class definition should be seen as an atomic unit with its own version control history.
Smalltalk/Pharo intrinsically doesn't focus on dealing with the Unix filesystem, because the Unix filesystem is what C deals with.
And yes, the answer is Iceberg exports the package of class definitions as a text file.
It is very useful to know whether I should load version 1 or version 2, or 3 of a (whole) package if somebody tells me they have a new version of their great package.
But main thing about git (and distributed version control) is not "trading source files". It is making changes by a distributed team to the same code-base and then being able to merge the changes made by multiple developers and having tools that help resolve conflicts between the different versions.
You can and often have multiple git-repositories. So if multiple developers were working on a Smalltalk package it might make sense to create a git-repo for just that package. But if the only file is the package-file then "merging" doesn't make much sense because you can't combine files changed by one author with files changed by the other authors.
So while I want to be able to 'control package versions" I also want to be able to "merge branches". And to support that it seems better to have many small files instead of a single big package file.
I agree that Smalltalk should be able to do better than a typical git-application because it knows about the semantics of classes and methods. And I think Smalltalk "change-sets" are a great concept. So I'm just interested in how Pharo tries to solve the tension between big package files versus multiple developers working on small code-units at the same time.
That's from way back, Smalltalk in the mid-80s.
page 462, Smalltalk-80 The Interactive Programming Environment
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf
https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1&dq=envy+developer&printsec=frontcoverOne reason they work so well is that Smalltalk treats methods as objects, not just as functions defined in some file. So a change-set knows it contains specific versions of specific methods. That is not possible in a typical git-environment where the most we know about a change is that it consists of some specific lines changed in a specific file.
People just coming to this might not realize that the Opensmalltalk-derived environments (Squeak, Pharo, etc) already had their own VCS system called Monticello, which worked pretty well once you understood the per-method diffs and how it was suited specifically to Smalltalk. The move to git -- Iceberg in Pharo and less so Squot for Squeak -- has left some of this behind in order to appeal to a broader base of orthodox programmers who might be otherwise scared off. It's kind of a shame.
The hosting infrastructure, GitHub issues and so forth, in the development community is absolutely critical these days.
Social networking tools to pull a programming community together are so important.
Pharo's case they've probably engineered git integration with a major goal of allowing people to contribute via GitHub issues.
I became accustomed to saving method changes and seeing a timestamped editions of that method; adding a version tag to what seemed like useful method editions; resolving any conflicts, then releasing a versioned method.
I kind-of liked the early visibility that gave of what other people were doing.
What prevents the pharo guys from simply providing their own merge tool and letting git call it?
The only remaining issue then is showing a file system tree and diffs out of the image e.g. a simple export that doesn't necessarily even have to be importable.
Second, for Pharo, the code (classes, methods...) are living objects. These objects are the working copy Pharo deals with. Not with the files. So it mostly works only with this object working copy + .git database. Another working copy of files (which other developers would use for editing, files outside of the .git directory) is just an additional source of problems and conflicts.
Pharo has a nice Git integration, and they spent a lot of time on making it work really well. So it has functions like browsing the history of one particular method etc. You are discussing already solved problems.
That is great functionality I think. Much better than basic git where changes are just changes to a set of lines. The unit of software should be classes and methods, not files.
The reason git can't do this is that it is language neutral.
However what I find interesting is that there is a corollary between git commits and Smalltalk snapshots. It would be great if we could "merge" Smalltalk images by checking out specific git commits and merging them together. The result would then be all the source-code in your current Smalltalk image.
It is difficult if not impossible to merge two Smalltalk images. Yet it would be useful to know what are the conflicts if any between two images. Maybe Pharo already provides something in that direction?
Merge changes, not images.
Even back in 1983, "Smalltalk-80: The Interactive Programming Environment"
"check conflicts
A prompter appears in which you type the name of a changes file. When you choose the yellow button command accept, an analysis is done of all the items in the change management browser menu to see if any of them refer to the same message selector, but specify different definitions."
page 472
http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...
What happened is that GitHub is titanically popular. So they went for Git integration as a compromise.
https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-Ma...