This is the first post in what I expect to be a series of posts
describing how I work with git and Smalltalk.
The content of this post is based on work that I have done over the
last 4 years working with FileTree[4], Metacello[3], tODE[1],
GsDevKit_home[2], and git.
It's important to note that while I will talk exclusively about git
in this series of posts, 99% of what I talk about can be directly
mapped to other disk-based SCM like svn, mercurial, etc.
I will describe the structure used by GsDevKit_home with the intent
to provide a reference point for discussion. The structure I am
describing is basically my third attempt at disk structure, so it
benefits from "mistakes" that I have made in previous attempts. I've
been using the current structure on a daily basis for the last 9
months, so what I'm describing is based on real-life structures and
code.
----
Currently,the fundamental pharo structure can be described as
consisting of: a vm, a sources file, an image file, a changes file,
and a package-cache. The vm and sources file are shared resources
and can be used with a collection of images. The image and changes
files are tied together as the changes files has the source for
methods that are in the image. The image and changes files are also
tied to specific versions of the sources file and vm... The
package-cache can be shared amongst a wide variety of images
including images created by different vms ...
When you plug git into the mix, you'll have a a local git repository
for each project that you have loaded in your image or intend to
load into your image. The git repository should be considered as a
resource that lies in between the package-cache and a changes file.
The git repository is not tightly coupled to the image like the
changes file (you can delete a git repository without impacting the
functionality of an image), but if you are making changes in the
image, then you _are_ coupled to a particular git commit identified
by its SHA.
Metacello will record the SHA of the git repository at the time that
packages are loaded from a git repository (to enable this feature in
Pharo, some methods need to be implemented in the MetacelloPlatform
for Pharo) and this information is stored along with the Metacello
registration for the project.
Since the git repository can be independently manipulated from the
shell or an image can be saved that references a SHA that is no
longer "current" .... it is very important that the SHA be recorded
and made visible to users via the tools.
In the early days of my work with git, I didn't have this feature
and it was very difficult to recover work from old images - I also
made mistakes by committing an older version of a package over a
newer commit ... nasty stuff ... Currently in tODE, i provide two
menu items to work with "version skew": `skew diff` and `skew save`.
The `skew diff` menu item just show the differences between to two
commits (the commit when the code was loaded and the current commit)
- if your project isn't dirty and the diff doesn't contain
unexpected changeds, then you may simple load the new commit into
your image and move forward.
The `skew save` menu item, basically does a merge between the code
in the image and the current commit - there a number of git
operations that go into this process: checkout original SHA; save
packages and�� commit; checkout custom branch from the "current
commit", merge new commit into the branch.
I plan on adding a `skew clone` menu item that does a git clone into
a repository directory that is reserved for use by the stone (image)
and then checks out the original SHA... this option would be more
useful for folks who "know what they are doing" and allow for
different work flows to be followed...
Soooo --- managing skew is an important function for the "project
browser"... Here's what the tODE "Project Browser" looks like when
version skew is detected:
Well I think that's enough for now...Here are some topics that I
plan to cover in future posts:
�� - what has to be done to get the initial clone and hook it into an
image?
�� - sharing git repos between separate "active images"
�� - cloning a github:// repos?
�� - ssh vs https clones
�� - working with remotes
Dale
[1] https://github.com/dalehenrich/tode
[2] https://github.com/GsDevKit/GsDevKit_home
[3] https://github.com/dalehenrich/metacello-work
[4] https://github.com/dalehenrich/filetree