>> No it doesn't.  And the fact that all the ones you mention do isn't a
>> strength.  All IDEs I know of surrender the *storage* of the repository to
>> something else, a file system, a database, a remote directory.  But lots of
>> Smalltalk environments keep firm control of their own source code control,
>> Store in VisualWorks, Orwell and later Team/V in Digitalk, Monticello in
>> Squeal/Pharo.  Just the addition of the simple version scheme in Squeak
>> changes & sources files puts it head and shoulders ahead of VisualWorks in
>> the ease of investigating history, undoing changes, etc.  This is vital to
>> the ease of programming, its flow, etc.  Squeak doers a great ob.  We
>> surrender that to something else at our peril.
>
> Mild talking past each other here. IntelliJ uses your favourite
> version control system under the hood to store your code: it supplies
> menus for driving, for instance, git to commit code and whatnot. It
> does, in addition, store versions for every time you hit enter (or
> after a period of time). These are distinct features. I'm not
> proposing losing the versions button or using git to store the data
> behind the versions button.
>
> I'm proposing that we keep the Monticello front end, add a few new
> buttons, and rip out the storage of source on disk, replacing it with
> git. I have yet to find a decent mapping of Smalltalk code to files,
> but I'd put up with a crap one if it meant one less thing that we
> didn't need to do.

The "storage" you refer to is already encapsulated by MCRepository.  I
would welcome a new MCGitRepository subclass if it were able to meet
the minimum API requirements of MCRepository.  But I see no need to
"rip out" any of the existing repository-types..

> Smalltalk was 30 years ahead of its time in 1980. It's now a decade
> behind other languages. That is a tragedy that, in my opinion at
> least, largely comes from the Smalltalk community's extreme
> insularity/NIH.

Again, I don't think this group will be moved by this line of
reasoning, even with such dramatic language ("tragedy?" c'mon).

Something that would be much more convincing, to me at least, would be
learning what having a MCGitRepository would do for MY goals and also
the community at large.  For example, I'm intrigued by Git's forking
capability.  How could that capability integrate into our ecosystem in
a useful way to bring more development power to the community?