However, sometimes you don't want all of these, for whatever reason. You don't want all those libs cluttering up your arc/ directory. You want to maintain maximal compatibility with the official release. Whatever.
For those reasons, I've added a stable branch to Anarki. It's just arc2 with as many bug fixes as are available and a very spare set of features added to make those fixes possible. It includes:
* Cross-platform "date" and "ensure-dir" * Compatibility with MzScheme 372 * Proper handling for Control-D in the REPL * A more efficient "whiler" * A fixed "codelines" (http://www.arclanguage.org/item?id=3753) * A fixed "minutes-since" (http://arclanguage.org/item?id=3726)
There are only two real non-bugfix differences between it and arc2. I added arc.sh because it's so handy, and I added the escape-to-Scheme $ macro, to make it easier to write cross-platform code. The latter could also be accomplished by adding more xdefs to ac.scm.
You can check out the stable branch as follows:
$ git clone git://nex-3.com/arc-wiki.git # Check out the repo
$ cd arc-wiki
$ git branch stable origin/stable # Create a local branch to track the remote stable branch
$ git checkout stable # Switch to your shiny new branch
$ git checkout stable # Get the stable branch
$ emacs # Make your edits
$ git commit -a # Commit all changes
Created commit 8668ce2: My informative commit title.
$ git checkout master # Switch to master branch
$ git merge stable # Merge in your change(s) to stable
$ git push # Push your changes to the remote repository
I hope this is helpful for everyone.
; If we're running Unix, MzScheme <371 has a bug
; where make-directory* sets the sticky bit.
; Thus, we want to use system instead.
arc> (mkdir "foo")
nil
arc> ^D
$ ls -l
total 0
drwxr-xr-t 2 cat cat 48 Feb 29 09:49 foo-----
And then you can ensure you have all bugfixes in the master branch by doing this.
git checkout master
git-merge stable
That way you don't have a human-error issue of some bugfixes going into one branch and not the other.
Git will handle the repeated merges, and the history (viewable with gitk) will make more sense, imho.
-----
As for merging, there are already some commits in stable that aren't in master, because their functionality was based on Anarki-only features in master. Merging would try to merge those as well, which may have unintended consequences. It might also double up a bunch of the commits in master, which would be unfortunate.
I'm still not all that familiar with Git, though, and I would love to have nice history. I'm all ears for suggestions.
-----
That would be a one-time headache with the first merge. After that, as long as bugfixes go into the stable branch, you won't have that problem. (Just had a quick look, it seems like it's currently a fairly trivial merge with only a few minor conflicts - I think git is doing the right thing for you here, but I don't know arc well enough to be sure).
> I would love to have nice history. I'm all ears for suggestions.
Basically, imho, splitting a tree is work and merging shouldn't be.
So by putting the commits in the right place to start with, you're avoiding work (and errors, and people checking with other people to see if that is supposed to be like that, etc).
You're essentially preserving more information as to the purpose of the fix (this is a bugfix) in a way that the tools can get hold of.
Anyway - I'm not a git expert, but that's the way I'd do it.
-----
I'm still hoping we'll get a nice way to get bugfixes directly into the Arc codebase though. No feedback from pg yet on the other thread. I am curious if there's a reason why he's unwilling to include things such as the date fix into the codebase. I suppose it could be just lack of time at this point.
-----
Yes.
Everyone has exactly the same amount of time: 24 hours in a day.
Every task that a person does means that there is something else that they are not doing.
To incorporate bug fixes sounds easy, but consider for example all the fixes floating around for "mkdir". Each one fixes mkdir for their operating system and their version of mzscheme, yet it's time consuming to ensure that a bugfix doesn't break someone else's installation.
When a bugfix has been tested and used by lots of people and there is a consensus that it is the right thing to do, then it would be easy for Paul to incorporate it into an arcn. When someone simply says "here's a fix!", then it takes a lot more time to figure out if it is the right fix and if it isn't going to make it worse for someone else.
-----
-----
There is a git command, 'git mergetool'. This will go through all conflicting files and launch an external tool (you can configure which) to handle the merge. If you save your merged results, it will git add for you, just leaving you to commit at the end.
(From the manpage) It has support for: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
Editing conflicted files by hand does work, but for complex conflicts I prefer the approach above.
-----
git clone git://nex-3.com/arc-wiki.git
Initialized empty Git repository in /home/jesin/arc-wiki/.git/
nex-3.com[0: 70.87.222.25]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
-----