There is a simpler way, using Git as it is meant to be used. Take a  
look at  
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/commit/3deff0d7b9707258766d6f003b783077664a4023#diff-5fe4c9854ae64b52029283e0648affd4 . We've been using this for a couple of years, and it works  
nicely.

Quoting Frank Shearar <frank.shearar at gmail.com>:

> On 20 November 2013 16:56, Chris Muller <asqueaker at gmail.com> wrote:
>>>> 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).
>
> I would use stronger language. I think our current state of affairs is
> a _disaster_.
>
>> 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?
>
> I'm actually tired of the whole argument. So, in lieu of further talk,
> I'm just going to carry on squirreling away on my stuff, chipping away
> at the dependency nightmare we have (and if you think that's
> hyperbole, you really ought to haul out graphviz and take a long, hard
> look at the dependency graph. Go make yourself some coffee while dot
> munges the file (which you can generate off
> https://gist.github.com/frankshearar/5781906)).
>
> Eventually we'll get to a place where I can not shiver in horror, and
> then I can think again about the git problem. Even better, maybe
> Camillo Bruni, Dale Henrichs and friends will have done the hard work
> for me.
>
> frank
>
>



Cheers,
Juan Vuletich