The command line has been outdated for 20 years.

This is the claim I heard yesterday from a colleague, along with a statement that he needs useable interfaces. The revelation came during a discussion about git vs MKS Source Integrity*.

Why, one might ask, comes Windows 8 Server, for the first time in history, without a GUI?  Why do retarded Linux freaks still claim that the command line is way more effective than any GUI?

The shocking answer is that, surprisingly, the command line is our natural way of communication since the dawn of the human race. We have an organ to form and send text streams. It’s called the mouth. We have another pair of organs that receive text streams. The ears, ladies and gentlemen. We also have a way of batch-processing these messages. Some would call it reading and writing. Others call it literacy.

That’s the reason that, against all odds, the only remaining paradigm of the last half century of computing is Unix, which embraced TEXT as its core value. Everything is a file, in other words a stream of characters, text.

What is the very essence of the C language, the ultimate superclass of all superclasses, which is compatible with everything by definition? It’s this, the pointer to the universal byte stream:

void *

And we’ve just arrived to the most crucial question. Why do so many people still despise the command line? Exactly. Because it involves learning languages.

But come on! By the age of two, everybody has learned one. It’s not that difficult. Of course, we all start with GUIs. We click our toys. We play with the mother of all GUIs, our Mom’s b… erm… buttons.

But as time passes, our parents watch with ecstatic joy as we form our first text streams. They tell their friends about it. Then we go to school and what do we learn first? Scripting.

I’ll go further. The command line is older than the human race. Text is more universal than the universe.

In the beginning was the Word, and the Word was with God, and the Word was God.

Chew on that, you serial clickers.

* Some would propose a better name: MKS Source Disintegration.

This page should serve as a summary of my experience with these two version control systems and a comparison of their possible workflows. There are four main areas where I shall compare them:

• Basics
• Development in a team
• Code reuse
• Integration with task-tracking

I have a lot of experience with MKS in all areas but, as I’ve been working with git on my private hobby projects so far, I’m very much limited to Basics and Code reuse here. Actually my goal with this page is to help me remember those awkward git commands.

1 Basics

1.1 Central vs Distributed Repositories

MKS is a client-server program. There is a central server that stores the repositories of each Project. People work with Sandboxes, private copies of a Project, that allow status tracking and all sorts of operations on the Project as well. A Sandbox is represented by a foo.pj file and the Working Files.
The server is usually under the control of a very busy and important admin, so don’t even ask me how to create a project. Just write him an email and in a matter of days you’ll have your new project. Another few hours/days will be needed to sort out access rights. To create a Sandbox, select the Sandbox/Create… menu item in the GUI. Or use the command line:

~$ mkdir foo
~$ si createsandbox --project=foo.pj foo # sandbox file foo/foo.pj is created

In git, you always have your own repository, represented  by the .git directory in the root of your project. To create a repo and a copy of the Working Tree, simply type

~$ mkdir foo && cd foo
~/foo$ git init

Or you can copy an existing repo anywhere (any URL is possible), similar to a Sandbox (but it’s more than that):

~$ git clone //bar/Projects/foo
~$ cd foo

The client-server concept of MKS seems superior at first sight, but I’m not sure. If the server’s backup strategy is not just-so, disaster is threatening, while in git every developer has a full copy of the entire repo. With MKS there is absolutely no way to track your work offline. Nor can you do so if you’ve received Read-only access only. Client server architectures are also very slow, as most operations go through the network. So on second thoughts, I’m absolutely sure: distributed is far superior.

1.2 Simple Workflow

I’ll cover adding and updating a file to the project. In both cases it starts with creating the file.

In MKS you can use the GUI: Member/Add, Member/Lock, Member/Edit Working File, Member/Check in, Project/Checkpoint. Or using the command line:

~/foo$ echo '#!bin/sh' > foo
~/foo$ si add foo
~/foo$ si lock foo
~/foo$ echo 'echo foo' >> foo
~/foo$ si ci --update foo
~/foo$ si checkpoint --sandbox=foo.pj

In git it’s far simpler:

~/foo$ echo '#!bin/sh' > foo
~/foo$ git add foo
~/foo$ echo 'echo foo' >> foo
~/foo$ git commit -a

1.3 Files vs Content

The reason for git’s simplicity is that it’s tracking content, not files separately. A “commit -a” will check in everything you’ve changed in your Working Tree as one atomic operation. Hence the lack of the checkpoint operation as well. An explicit “add” is only necessary for new files.

Note: If you use commit without -a, you need “git add” for each changed file as well before commit.

2 Development in a Team

MKS handles co-operation with a repo on the central server, private sandboxes and file Locks. A Lock means that only the locking developer is allowed to Check In the locked file. It’s very controlled, but may result in deadlocks if multiple people want to edit the same file. The second wannabe locker has to wait for the other’s checkin, merge the new revision into his Working File, lock and check in. The problem can be mitigated with good software-design based on nicely separated modules where people seldom queue up for a single file.

Git, on the other hand takes all this in its stride, considering multiple people working on the same file at the same time as a fact of life. The key is easy branching and merging. I’m not practiced but is seems the key operations are:

~/foo$ git pull # update you cloned repo with newest commits
~/foo$ git checkout -b newfoonction # create branch for development
~/foo$ echo 'echo newfoonction' >> foo
~/foo$ git commit -a
~/foo$ git push # publish your branch to original repo

Then it’s up to the maintainer of the main repo to merge the new branch to master. More of that later when I get some practice.

3 Code Reuse

MKS enables code reuse with the Shared Subproject concept. Project “foo.pj” that resides on the central server can be inserted into Project “bar.pj” into an arbitrary subfolder under an arbitrary name. You can also specify to reuse a certain Checkpoint of Project “foo.pj” (Build), or develop on it’s mainstream (Normal) or DevelopmentPath (Variant). In the latter two cases you’re able to Lock, Check In files and Checkpoint your Shared Subproject foo.pj from within the reusing bar.pj. You can also change between a fixed checkpoint (Build), mainstream (Normal) or DevPath (Variant) development, using the Configure Subproject menu item.

Git does this with submodules. Development from within a main project is easier, as remote clones of your main repo always see a specific commit of your submodule, never the index (like a Normal or Variant Subproject in MKS). But simple operations like updating your submodule to different versions or pulling from a repo containing submodules is tricky.

Below, I’ll list a few MKS Subproject related operations and give the closest git equivalent of them.

3.1 Add Shared Subproject

This MKS operation inserts another Project into a reusing Project’s folder structure.

~/bar$ git submodule add ~/foo foo
~/bar$ git submodule update --init

3.2 Resync Sandbox Recursively

Let’s assume bar is a cloned repo, containing submodules.

~/bar$ git pull
~/bar$ git submodule update

3.3 Configure Subproject to latest Build

~/bar$ cd foo
~/bar/foo$ git checkout HEAD
~/bar/foo$ cd ..
~/bar$ git commit -a

3.4 Configure Subproject to ANY Build

~/bar$ cd foo
~/bar/foo$ git checkout HEAD^^ # 2 versions before newest
~/bar/foo$ cd ..
~/bar$ git commit -a

3.5 Develop Subproject from within Main Project

Coming soon…

3.6 Drop Subproject

Coming soon…

4 Integration with Task-Tracking

MKS contains a full bug/task tracking tool called Integrity Manager, fully integrated with its version control called Source Integrity. The task/bug unit is called “issue” and its linked with version control operations via “Change Packages”.

As far as git is concerned, task-tracking is not built in, but you can find stunning web based solutions in free software projects. Midnight Commander’s Trac-git combo springs to the lips.

I always wanted to try out something like that. My bro mentioned they use Redmine at the office. I gave it a try, and it integrates with git so easily and beautifully, that I did not want to believe my own eyes. It’s become a semi-official tool at our place as well.

One needs sort of a central git-repo on the server where the Redmine web-app runs. This repo should be the one where everyone pushes. Redmine offers issue-tracking, which is slightly better than that of MKS, and to connect a git-commit to an issue, one has to mention the issue number in the first line of the commit message. Yes, it’s that simple:

1cd87ac Fix foo to avoid a bar-baz interference #42

The above line is from a oneline git-log, showing part of the SHA1 id of the commit and the commit-message. When such a commit is pushed to the central repo, it automatically connects it to issue 42, which in turn lists all related commits. No hassle with check-ins and Change Packages. Just commit and push.

Not to mention Redmine’s excellent web-based repository browsing.

The scariest free open-source tool of all – Git – proved to be one of the best. Again.

It is scary. I grew up on MKS, with a nice GUI, a central repository and files locked for editing. With git all that is blown out of the window. Instead, you get cryptic commands (git bisect bad, anyone?), a separate repo for everybody, branches and merges.

After the initial shock, which may have lasted a few months I must admit, I begin to see MKS Source Integrity as a broken tool. Nice GUI? It crashes after a few hours, anyway. Central repo? Why can’t I work off-line? And why shall I wait ages until someone breaks his lock for me? And it takes only one “git commit -a” to realise that those Check-ins, Update-Members and Checkpoints may be a bit over the top.

My most recent discovery in Git was submodules. It’s for reusing code. I realised that I had implemented the -h/-V switches (for help and version display) in multiple projects separately. That’s a cardinal sin, while constructive laziness is the cardinal virtue.

So I created a project called arg1 with a single module with a single function, which takes your program’s argv[1] as an argument, checks whether it’s -h or -V and prints the usage or version text respectively if it is, and exits.

void arg1Eval(const char* arg1);

The texts shall be stored as simple text-files (usage.txt and version.txt) in the reusing superproject’s up-dir. The arg1 project contains a makefile as well, which turns these txt files into .h files with a string initializer-list. It’s made by a tricky sed command:

%.h: ../%.txt
 @sed -e 's/[ \t]*$$//g' -e 's/^/"/g' -e 's/$$/\\n",/g' <$< >$@

To reuse this little thing in your project simply type

git submodule add ~/Projects/arg1 arg1

Now comes the best part: Instead of reusing something from your filesystem (~/Projects/arg1) you can use any URL. You can reuse the whole internet. You can even develop that submodule from within your main project.

My new MKS vs Git page explains a lot of submodule related functionality.

After switching to Linux, one feels the need to switch to an equally cool version control system as well. And none is cooler than the one invented by Linus Torvalds himself: Git.

It’s called the Fast Version Control System. Being an MKS user professionally, git was a bit on the scary side. No GUI, strange commands and a completely different workflow. Instead of the central repo, there is cloning, pulling and pushing. Instead of the rigid but readable version numbering, there are unreadable SHA1 hashes but, at the same time, user-defined tags as well. Instead of locking, there is branching and merging. Instead of dealing with separate files, there is the universal commit. Main advantage: FAST! And I feel the workflow more and more natural.

I could not get used to one thing, however. The “git diff” command displaying source differences. I’m a huge fan of command lines, but there are limits. So I googled for a visual difference tool. I found meld.

sudo apt-get install meld

Then I looked for a way to integrate git and meld, so when I type git diff, it would open meld, instead of displaying that unreadable mess on the terminal. I found Nathan Hoad’s website.

First step is to tell git it should use meld. While the Bash Guru types

git config --global diff.external meld

the Config Wizard adds a few lines to ~/.gitconfig:

[diff]
  external = /usr/bin/meld

It does not work, however. Git sends 5 parameters to the diff tool, while meld expects only the 2 filenames to compare. So a little filter is needed. Nathan Hoad proposes a Python script:

#!/usr/bin/python
import sys
import os
os.system('meld "%s" "%s"' % (sys.argv[2], sys.argv[5]))

I know that Python is the language of the day, but in this case I felt it was a bit like Shooting a Sparrow with a Cannon, if you allow me this Hungarism. If one is lazy, one needs a one-liner. And the language of choice is non other than the Bourne Again Shell. The filter is called ~/gitvdiff:

git config --global diff.external ~/gitvdiff

And it contents:

#!/bin/sh
meld $2 $5

Let’s see the results.

On the right side you may notice the entire source file displayed. With syntax highlighting. With a map of the diffs. And with the diffs nicely highlighted.