<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Thank you very much also from my side, Jakob!</p>
<p><br>
</p>
<p>Did you already copy this documentation somewhere into the swiki? If not, I would propose doing so.</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis@mail.msen.com><br>
<b>Gesendet:</b> Dienstag, 2. Juni 2020 03:22:40<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] [ANN] Git Browser and Squot</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Jakob,<br>
<br>
Thank you for this comprehensive overview, it is *really* helpful.<br>
There is lot here to read and absorb, and some of it will take<br>
time for me to absorb.<br>
<br>
Thanks a lot for taking the time to explain, I really appreciate it.<br>
<br>
Dave<br>
<br>
<br>
On Sun, May 31, 2020 at 09:30:53PM +0200, Jakob Reschke wrote:<br>
> Hello together,<br>
> <br>
> Over the past two years you may have seen occasional mentions of<br>
> ???Squot??? and more likely of the ???Git Browser,??? which can be installed<br>
> from the menus of a plain Squeak image since 5.2. In case you ever<br>
> wondered: Squot and the Git Browser belong together. Let me finally<br>
> introduce you to them today, since this is the outcome of my master<br>
> thesis from back in 2017.<br>
> <br>
> ==What is Squot?==<br>
> <br>
> Squot is a version control system (VCS) for objects. Not only<br>
> packages, but arbitrary objects (such as Morphs, so you do not have to<br>
> put Smalltalk instructions how to recreate it in the VCS, but you can<br>
> rather track the object itself).<br>
> <br>
> It uses an external VCS as its backend to store versions. As of now,<br>
> only one implementation for Git exists (except for some test stub<br>
> repositories for the unit tests). It should be possible to add further<br>
> backend VCSs without changing the core of Squot.<br>
> <br>
> Squot is an abbreviation of ???Squeak object tracker,??? loosely based on<br>
> Git???s description in its manual page: ???git - the stupid content<br>
> tracker???.<br>
> <br>
> ==What is the Git Browser?==<br>
> <br>
> The Git Browser is a graphical user interface to operate on Squot<br>
> working copies with a Git repository as a backend. It allows you to<br>
> manage working copies, track packages (multiple per working copy,<br>
> which are all versioned together), browse branches, create new<br>
> commits, search for commits, synchronize with remote repositories, and<br>
> perform checkouts and merges. It can be used without a Git outside of<br>
> Squeak (it does not call external processes or shared libraries).<br>
> <br>
> The tool is primarily meant to maintain Squeak projects, which are<br>
> published on GitHub or similar platforms, but can be used with any Git<br>
> repository.<br>
> <br>
> ==Is it ready for use?==<br>
> <br>
> To work on Smalltalk projects: definitely yes. It has been used for at<br>
> least three years in student courses at HPI (Potsdam). I am also using<br>
> the Git Browser to work on Squot itself.<br>
> <br>
> To really track other objects than packages: possibly. It has some<br>
> bugs left, so I would not recommend to rely on the tracking of objects<br>
> other than packages for production use. For this reason, there is also<br>
> no GUI yet to add other objects to a working copy in the Git Browser.<br>
> <br>
> There are occasional quirks when pushing to GitHub (???Connection<br>
> closed???), so you might need to resort to the Git CLI sometimes.<br>
> Currently you must also merge non-Smalltalk files outside of Squeak.<br>
> To view the commit history as a graph, you can use external tools,<br>
> such as gitk, SourceTree, or whatever your preferred Git GUI is.<br>
> <br>
> ==How can I use it?==<br>
> <br>
> 1) Install the Git Browser by choosing Tools > Git Browser in your<br>
> Squeak image (since 5.2). This will also load several of dependencies<br>
> via Metacello.<br>
> <br>
> 2) Once you have the Git Browser open, it will prompt you whether you<br>
> want to create your first project now. If you would like to start a<br>
> fresh and empty working copy on an empty Git repository, select ???yes???<br>
> and provide a path for the Git repository. If you would rather like to<br>
> clone an existing Git repository, select ???no.???<br>
> <br>
> 3) The Git browser itself has five panes:<br>
> <br>
> * On the top left, there is a list of projects. These are your<br>
> working copies. Each working copy links something in your Squeak image<br>
> to a Git repository outside of that image. Via the context menu of<br>
> this list, you can add, change, or delete working copies and<br>
> repositories. If this list is empty, you will want to start with the<br>
> context menu here.<br>
> <br>
> * Below that, there is a list of branches in the currently<br>
> selected project (if any). Via the context menu, you can add, rename,<br>
> and remove branches, push to remote repositories, and switch branches.<br>
> One branch is highlighted with a green dot; this is the branch that is<br>
> currently checked-out. If you create new commits, they will go on this<br>
> branch.<br>
> <br>
> * On the top right, there is the list of commits on the current<br>
> branch (if any). You can compare commits with each other or a commit<br>
> with the working copy, search for commits using the search bar below<br>
> the list (or via list filtering to only search the headlines), create<br>
> a new branch at a commit, reset the current branch to an older commit,<br>
> or check out or merge specific objects from a commit.<br>
> <br>
> * In the bottom-left pane, the full log message of the selected<br>
> commit will be displayed. In addition to that, it will also show the<br>
> commit metadata, such as the author, committer, and the abbreviated<br>
> SHA-1 hash of the commit and its parents.<br>
> <br>
> * Finally on the bottom right, there is a list of objects in the<br>
> selected commit. These are usually the packages known in a particular<br>
> commit. Via the context menu you can checkout or merge an object with<br>
> the working copy (read checkout like ???Load??? in Monticello and merge<br>
> like ???Merge???), browse either the object as it was at the time of the<br>
> commit, or what is currently loaded. You can also access the current<br>
> scripts (preamble, postscript etc.) of packages here.<br>
> <br>
> 4) Between the panes, there is a strip of buttons. They operate on the<br>
> current branch or the selected commit. At the far right, you can<br>
> configure how things go to Git: that is your name and e-mail address<br>
> for the commit metadata, the Smalltalk file format you want to produce<br>
> (FileTree/Cypress or Tonel), and whether Squot should suppress writing<br>
> its own configuration files (if you want to submit a pull request to a<br>
> repository that is not developed with Squot, for example). Via the<br>
> Feedback button, you can create an issue for Squot on GitHub directly<br>
> from the image. You can also file these here:<br>
> <a href="https://github.com/hpi-swa/Squot/issues">https://github.com/hpi-swa/Squot/issues</a><br>
> <br>
> 5) To add another package to a project, or remove a package from the<br>
> set of tracked packages, open the menu of a project and choose ???Change<br>
> tracked packages???. Below that menu item, you can also change between<br>
> writing FileTree/Cypress or Tonel files (???Set package storage<br>
> format??????).<br>
> <br>
> 6) When you switch branches via the context menu of the branch list,<br>
> note that it will stow away all your unsaved changes and the other<br>
> branch is checked out clean. Your unsaved changes will be restored<br>
> when you switch back to the original branch. This behavior is<br>
> different from the Git CLI, and was conceived in an alternative Git<br>
> frontend called ???Gitless??? (which addresses some of Git???s awkwardness).<br>
> <br>
> 7) When you want to commit, you will find that there is no Git staging<br>
> area as far as the Git Browser and accompanying tools are concerned.<br>
> Instead, you can choose which packages, classes, and methods you want<br>
> to include or exclude in the commit dialog, like in Monticello in<br>
> recent years.<br>
> <br>
> 8) When you checkout or merge something, you always first get a list<br>
> of changes, from which you can choose what to load and what to skip.<br>
> <br>
> 9) To update the Git Browser when a new version was published, open<br>
> the window dropdown menu (third button from the right in the title<br>
> bar) and choose ???self-update??????. It pulls the latest version from the<br>
> master branch on GitHub. Ongoing development happens on the ???develop???<br>
> branch, not on master. You can also pull that version by choosing ???set<br>
> self-update branch?????? in the same menu, and then invoke the update.<br>
> <br>
> ==How does it work internally? Why is it not a Monticello extension?==<br>
> <br>
> Squot knows of three presentations of an object: 1) the ???live??? object<br>
> that is ???the real thing,??? which you can normally handle in Squeak, 2)<br>
> one or more ???shadows??? of the object, which is a captured<br>
> representation of one version of the ???live??? object (a snapshot); it is<br>
> used to reason about different versions of the same object without<br>
> loading them, 3) a ???stored??? object, for example serialized into a<br>
> file. Objects are tracked in graphs of objects. You add an object<br>
> graph by adding a ???root object??? to the working copy, from which all<br>
> the other relevant objects can be reached. For example, you could add<br>
> a complex Morph, which would include all of its submorphs. The tracked<br>
> objects can to a certain degree control how they are captured; for<br>
> example, the ???root Morph??? will direct Squot to ignore its #owner<br>
> instance variable (because otherwise you would always track the whole<br>
> World). To be able to identify an object in different versions of a<br>
> graph, each object gets a unique name assigned when it is first<br>
> captured. Objects may opt out of getting a name if they are true value<br>
> objects for which identity does not matter when a shadow object is<br>
> rematerialized to a live object during a load/checkout. Identity does<br>
> not matter when it makes no difference whether two objects refer to<br>
> the same instance of the value, or a different, equal instance (like<br>
> Number, Point), or if there is only one instance by definition (like<br>
> UndefinedObject, Boolean, Symbol).<br>
> <br>
> Packages, which are the only kind of object you can currently track in<br>
> Monticello (besides configurations of packages), are just a special<br>
> case of all of this. Read the rest of this paragraph as an example of<br>
> what I wrote in the previous paragraph. The live package is<br>
> represented by its PackageInfo. It subsumes the loaded behaviors and<br>
> methods that are attributed to the package. A shadow package basically<br>
> wraps an MCSnapshot of the package (Squot reuses MCSnapshots and<br>
> MCDefinitions under the hood to represent shadows of packages,<br>
> behaviors, methods). A stored package is a tree of files in<br>
> FileTree/Cypress or Tonel format, for example. In theory, it could<br>
> also be any other file representation, such as a plain file-out, or a<br>
> SmartRefStream that contains the MCSnapshot. A PackageInfo is the<br>
> ???root object??? of a package object graph in the working copy.<br>
> PackageInfo will tell Squot that it does not want a unique name<br>
> assigned, because a PackageInfo is already identified by its<br>
> #packageName. To create the shadow package, PackageInfo also overrides<br>
> the capturing process for Squot to find the classes, and methods<br>
> (which are not directly referenced) and turn them into an MCSnapshot<br>
> with Monticello. When a package is loaded in Squot, it will also use<br>
> Monticello to actually install the changes.<br>
> <br>
> As a general way to capture any kind of object, Squot has shadow<br>
> classes to capture objects as collections of slots that refer to other<br>
> objects. Instance variables and indexed variables are two basic kinds<br>
> of slots in this model. Specializations in this model are also<br>
> possible: for example, Sets and Dictionaries use special kinds of<br>
> slots for their elements or associations, so Squot does not capture<br>
> their internals (the hashtable array and tally) instead. It takes into<br>
> account that associations can be shared among multiple Dictionaries<br>
> (like Bindings).<br>
> <br>
> Squot does not reuse the existing repository and versioning<br>
> infrastructure of Monticello. I did this to be free of the constraints<br>
> of the contemporary Monticello, and to not break it while developing<br>
> Squot and its companion packages. Some concepts are also different: in<br>
> Monticello you have packages and versions of packages, in Squot you<br>
> have versions, each of which can contain one or more packages (or<br>
> something else). That is, a Squot version could be viewed as a version<br>
> of a configuration map. This maps better to the concepts of popular<br>
> file-based version control systems like Git, Mercurial etc. Moreover,<br>
> a Squot repository is not just a store for versions; it also knows<br>
> branches (the managers of history).<br>
> <br>
> The Git Browser belongs to a package called Squit. Squit connects<br>
> Squot and Git, like its name does. It provides Squot repositories and<br>
> versions, that are in fact adapters for Git repositories and Git<br>
> commits. To maintain the actual Git objects, Squit uses a package<br>
> called FileSystem-Git, which allows developers to browse files in Git<br>
> commits like regular file trees using the FileSystem API. (This was<br>
> the first effort to support a Git implementation in Pharo, until Pharo<br>
> abandoned it in favor of the libgit2 binding. If I remember the author<br>
> timestamps correctly, FileSystem-Git was primarily developed by Max<br>
> Leske, Camillo Bruni, Damien Cassou. The core Git classes are in turn<br>
> based on the ones written by Tony Garnock-Jones, which can still be<br>
> found on squeaksource. I converted FileSystem-Git back from Pharo to<br>
> Squeak and made it work for its purpose (it is not a feature-complete<br>
> Git, but you can read and write local and remote repositories<br>
> correctly). Much of the work has already been done by the others, but<br>
> some things needed to be fixed or added to make it usable. To that<br>
> end, I revived the Squeak implementation of FileSystem and extended it<br>
> where necessary. As of now it is not fully compatible with the API in<br>
> Pharo (class names and some method names are different), but that is<br>
> still not impossible to change.)<br>
> <br>
> More details can be found in our technical report [2].<br>
> <br>
> ==Closing words==<br>
> <br>
> I hope you will have fun using Git with Squeak.<br>
> <br>
> Thanks to all those who have contributed to this project (and its<br>
> dependencies/ingredients) so far!<br>
> <a href="https://github.com/hpi-swa/Squot/graphs/contributors">https://github.com/hpi-swa/Squot/graphs/contributors</a><br>
> <br>
> Kind regards,<br>
> Jakob<br>
> <br>
> [1] <a href="https://www.hpi.uni-potsdam.de/swa/publications/">https://www.hpi.uni-potsdam.de/swa/publications/</a><br>
> <br>
> [2] <a href="https://www.hpi.uni-potsdam.de/swa/publications/media/ReschkeTaeumelPapeNiephausHirschfeld_TowardsVersionControlInObjectBasedSystems_HPI121.pdf">
https://www.hpi.uni-potsdam.de/swa/publications/media/ReschkeTaeumelPapeNiephausHirschfeld_TowardsVersionControlInObjectBasedSystems_HPI121.pdf</a><br>
> <br>
> <br>
<br>
</div>
</span></font>
</body>
</html>