Note for regular readers (if I have any): this post is specific to the Arc community and probably incomprehensible to anyone outside it.
So after much dithering on my part about how to handle the update to arc3, and especially regarding how to cleanly incorporate CatDancer's ideas about sharing hacks, I've decided to forget about all that difficult stuff and just use the old model. More on the reasons for that below, but first, what I've done to anarki.
The old arc2-based
hygiene branches of anarki have
arc2.hygiene respectively. The
stable branches are based on arc3.1. However, in case you
haven't been following along until now, they are not simply the merge of the
arc2-based branches with the changes made to reach arc3.1. I determined that a
complete or even partial rewrite of the arc2-based anarki code would be too
difficult; again, see below for rationale.
Instead, they have entirely new development histories based on the
branch (currently at arc3.1.tar). I've hand-ported the features I most liked
from arc2-based anarki, with some important changes, intended to reduce cruft in
the long run so that porting to arc4.tar, when it comes, won't be such a pain in
Unfortunately, this means that updating to the new anarki is not as simple as
git pull, because merging your local
stable with anarki's
updated branches would be disastrous. I'll repeat this, because it's important:
do not simply pull from anarki as you have done before. It will not work.
In fact, the easiest way to handle the update is to just
git clone a fresh
email@example.com:nex3/arc.git. Then, if you have any work in your old
local repo you want to transfer, do so by hand. However, for those who don't
wish to do this, explanation follows.
Updating without cloning a new repo
Assuming you don't have any unpushed commits or changes you don't care to lose on your master and stable branches, then the following should "just work":
$ git pull origin +master:master +stable:stable
If by chance you're also tracking my hygiene branch, add
the end of that command. If you're not tracking the stable branch, remove
For those interested, this command tells git to pull the
branches from the origin remote (anarki) into the correspondingly-named local
+ at the beginning of the refspecs indicates that the local
branches should be forcibly updated, ignoring the fact that they have a
different version history from their remote versions (that, in git parlance, the
update is not a "fast-forward").
If you do have unsaved work you want to keep, then instead you'll have to rename your branches:
$ git branch -m master arc2.master $ git branch -m stable arc2.stable # only if you track the stable branch $ git branch -m hygiene arc2.hygiene # only if you track the hygiene branch
After this, update your .git/config file to change what remote branches they're tracking:
... [branch "arc2.master"] remote = origin # merge = refs/heads/master # BEFORE merge = refs/heads/arc2.master # AFTER ... [branch "arc2.stable"] remote = origin # merge = refs/heads/stable # BEFORE merge = refs/heads/arc2.stable # AFTER ... [branch "arc2.hygiene"] remote = origin # merge = refs/heads/hygiene # BEFORE merge = refs/heads/arc2.hygiene # AFTER ...
After you've done this, it's safe to
git pull from any of the branches.
However, you won't yet have any of the remote arc3-based branches. To fix this:
$ git fetch $ git branch -t master origin/master $ git branch -t stable origin/stable
Why not just merge pg's changes into anarki as it was?
The changes between arc2.tar and arc3.tar are many and significant. The changes between arc2.tar and anarki's core files are even more numerous. Merging these two sets of sometimes wildly divergent changes correctly is a task beyond me. Even were this accomplished, much of the non-essential code on anarki (libraries, etc.) would need updating. While in most cases updating to arc3 might be simple, the sheer volume and variety of code prohibits it being done by any one person; whereas leaving a pile of crufty nonworking code around is, first, horribly confusing to any newcomer who wants to get acquainted with what anarki has to offer, and second, aesthetically unpleasing (to say the least).
So instead I've made a clean start. Instead of porting arc2-anarki wholesale, I've forward-ported the features I myself most wanted, and I encourage everyone else to do the same. That way, we'll end up (eventually) with all the features of arc2-anarki that people actually used, and none of the dead weight.
Speaking of which, this new start provides a perfect opportunity to cull some of the cruft that infested arc2-anarki. In particular, I'm thinking of the things that made porting anarki to arc3 so difficult: lots of changes to core files, little documentation of added features, and poor separation of the code that adds features. Read on for more information on this last point.
Ported and changed features from arc2 anarki
The most significant things I've written for and ported to arc3-anarki are an
improved $ special form, programmable
coercion, anarki's old interactive help
fns, etc), and an improved version of anarki's extended
This last one provides an opportunity to showcase another thing I've added: a
CHANGES/ directory. Arc2-anarki made a lot of extensions to arc, but most of
those features can only be discovered by looking through the source code —
a time-waster even for an experienced arc hacker, and simply not workable for a
newcomer — or reading the posts people make about them in the forum
— a good way to keep up on new developments, but not so good for
discovering long-established hacks. So, in future, I encourage other anarki
hackers to document their changes by creating a file in the
directory; and as an example, I'll point you to the documentation for the new
I've also added another directory,
.arc files in this directory
are auto-loaded by
libs.arc when arc is started up. The intention here is
that, instead of putting useful language additions like
arc.arc, you can add a file in
load/ which defines them. This
avoids "polluting" core arc files, reducing the difference between
anarki as compared with
arc.arc from arcn.tar; and like
CHANGES/, it makes
feature discovery easier for a newcomer.
Addendum: what about CatDancer's "hacks" model?
In brief: too difficult to scale manually, couldn't find a good tool, implementing it in git pollutes the version history with a lot of merges, and ultimately extracting the hacks myself was easier than trying to maintain them independently.