# Starting to play with git

Been a mercurial user for a while, mercurial was IMO more mature when we started using it about 1.5 years ago. Git was new, and not quite as easy to deal with.
What a difference 1.5 years make. I find starting/importing new projects with Mercurial harder than I like. Its not bad, it just takes a bit more thinking than I want during import.
So I tried git tonight. Imported the deltaV tools in.
Like butta (like butter, e.g. smooth, easy, and tasty).
Creating the repository was easy. Moving data to it was easy. Almost trivial.

Its a little more complicated in Mercurial, but not much.
Put it another way … way way back in 2000, we had a CVS repository. CVS was/is terrible. Too many things are broken. It is too easy to mess up with it.
Subversion came along, promising to fix many of the things that CVS got wrong. It didn’t. And it added a webdav “requirement”. I was not able to get a working subversion installation going. And I tried off and on for years.
Found Mercurial while looking for alternatives. Mercurial is good, but it is dependent upon some python bits/configuration that is at least mildly annoying. This isn’t a Mercurial issue apart from Mercurial being a python code.
Took under 10 minutes to get my first repository going, took another 10 or so minutes to get the rest of the system working. Then setting up the web interface, and making sure remote commits worked took another few hours.
Tonight I started with git. I created a repository, set up ssh keys, and imported the deltaV tools from the engineering unit inside of about 2 minutes, inclusive of the time to copy and paste the ssh keys, add and commit the stack, and finally move it to permanent storage.
Um … we have a winner.
Tomorrow I will install the web tools. I’ll also make a set of public git repositories. I’ll leave our existing public hg repository up, but will push new bits to git.
Good work folks … Hopefully ActiveState Komodo integrates with it now (it does with Mercurial!).

### 4 thoughts on “Starting to play with git”

1. Just curious (because Open MPI is in the slow process of migrating from SVN to Mercurial): is your favoring of git because you long-ago made the mental leap from centralized VCS’s to DVCS’s, and therefore the mental delta (no pun intended) from Mercurial -> Git was fairly small?
I have always thought of svn, hg, and git as somewhat of a linear spectrum: svn at one end, hg in the middle, and git at the other end. hg and git are both DVCS’s and fairly feature-comparable, but hg’s commands are much closer to svn’s, making it easier for cvs/svn dinosaurs (like me) to switch to hg (compared to switching to git).
I use git about once every 6 months (typically interacting with someone else’s project) and it always confuses the heck outta me. The next time I use it is just long enough later that I forgot everything I learned the previous time. Plus, 95% of my day is still comprised of working with SVN (read: a non-DVCS), so all the concepts are not kept fresh in my head. So I have mental models in my head that git is extraordinarily complicated and difficult to learn, and that Mercurial — although it’s a DVCS — is much closer to the stuff that I currently use every day, and therefore is much easier for me to learn and migrate to.
So my question to you is: do you think your experience / bias / whatever is that it’s a natural evolution from CVS -> SVN -> Mercurial -> Git? (vs., for example CVS -> SVN -> git)
Also, what motivated you to look (again) at VCS’s and move to a new one? Is Mercurial somehow deficient for your requirements / needs? You mentioned that git seems a little easier to make new projects — do you do that often such that it’s worth the mental delta to learn a new system (and genuinely be *more* productive)? And/or even since the mental leap from SVN -> Mercurial is clearly long-since overcome and there’s nothing new you need to learn to do what you need to do with Mercurial, what makes git “better” such that it makes the git mental bootstrapping worth it?
(keeping in mind that all of these questions may be attributed to the fact that I have a [potentially inaccurate] complex model of git in my head, as described above)
Thanks!

2. @Jeff
My path to git was a slow/tortuous one. Understand that I was raised in sccs days, so CVS was (initially) a great help. Until I tried removing files that shouldn’t have been committed. I could use CVS, but as often as not, hung it. The syntax wasn’t all that lucid, and often minor typos could cause significant damage (well, ok, my minor typos could).
I tried to set up an SVN repository. I never was able to. Various things kept getting in the way … usually apache and apache configuration/permissions. SVN pretty much requires that it owns (at least in the early days) all of apache. You really need a separate apache instance running out of its own tree to make it work right without harming your other web servers. So I did that,and it was hackish. Some things just would not work.
So for a short interval, my version control was tarballs with dates embedded in the name. It works, and it worked better than SVN for me … which was unfortunate.
I stumbled across hg around the time git adoption started going fast. I had looked at git (back then) and it was (then) the poster child for arcane usage. hg didn’t look too hard, so I pulled it down, and setup some repositories.
I often code on my laptop, so a localized/distributed repository is not a bad thing. Also, back then I had a developer working on DragonFly (our cluster/HPC UI code), and we needed to coordinate our work. So I set up hg, and off we went.
For the most part, it worked fine, though I had to keep reminding people to commit their changes back to the central tree, or send me their trees/allow me access so I could do the commit.
The hardest part about hg is still setting up new repositories. There are permissions issues, and a bunch of other things that are sufficiently annoying that I found myself avoiding using it for some of my projects.
This didn’t make sense. I want to be able to start a project quickly and easily, and not have to do an initial checkout to import a code.
It came to a head for me this past week when I realized I was back to dated tarballs.
Thats just wrong.
So I looked at mercurial 1.1.1, and worried if I installed it atop my 1.0, would I cause a problem. Still concerned about this, I want to try it on another machine first.
Ok, but I still need a VCS. So I thought with high profile projects like Perl moving to git, and the apparent momentum behind it, maybe I better look again.
So I googled for “git tutorial” and came up with this

Assume you have a tarball project.tar.gz with your initial work. You can place it under git revision control as follows.
$tar xzf project.tar.gz$ cd project
$git init Git will reply Initialized empty Git repository in .git/ You’ve now initialized the working directory–you may notice a new directory created, named “.git”. Next, tell git to take a snapshot of the contents of all files under the current directory (note the .), with git-add:$ git add .
This snapshot is now stored in a temporary staging area which git calls the “index”. You can permanently store the contents of the index in the repository with git-commit:
\$ git commit
This will prompt you for a commit message. You’ve now stored the first version of your project in git.

Cool, not hard. About on par with hg, but hg requires (generally) an ‘hg merge’ step as well.
Ok, now how hard is it to set up a repository. I googled for setting up a git repository and found this link.
There, it was (after adding the git user and setting up ssh keys) painless.

Create a Repository
Next we will make a repository. For this example we will work with a repository called example. Login as the user git and add the repository.
ssh git@REMOTE_SERVER
# once logged in
mkdir example.git
cd example.git
git –bare init
That???s all there is to creating a repository. Notice we named our folder with a .git extension.

ok, what about the remote repository access? Between setting up a new repository and remote access, these are the two IMO weakest parts of hg. hg is very good, but occasionally frustrating to deal with (having to go back and mess around with permissions).
So here is the committing to a remote repository:

Commit to Remote Repository
Finally all you need to do is add your files to the remote repository. We will assume you don???t have any files yet.
mkdir example
cd example
git init
git commit -m ‘first commit’
git push origin master
replace REMOTE_SERVER with your server name or IP

git commit -m ‘update’
git push origin master
Not painful. This is what I wanted. Ease of repository setup (so we can set up internal customer porting/coding projects easily), ease of remote interaction, so we can use the system.
hg has most of this, and is very good. It just never worked very well for repository setup and the interactions were sometimes convoluted (and required operator intervention on remote repository to fix permissions). If you have one person using the repository, these won’t be issues. If you have several … this could be a problem.

3. I evaluated git for about 1/2 day last Nov and I really liked it. We are using Subversion (svn) and initially I ran into several limitations (I do not remember what they were). That all said, svn is good enough for our needs, I do not see a strong enough justification to replace it, at least for now. I’ve used many VCSes: Clearcase was the most feature-complete, but also the most expensive and intrusive. I think that there are many decent choices these days. My friends in Boston use Bazaar (from Ubuntu / Canonical), bazaar-vcs.org.