Getting Git + SSH to play nice with the COSC Servers...

This post is more of a little reminder-to-self should I forget how to get this working again in future. The intro below gives a bit of background info about the situation of how I came to be using Git, but also the troubles trying to get it to work with the SSH/Remote access to my department's Linux servers.

Background
I've been using Git for most of my projects over the past few years now. IIRC, it was in late 2011 that I started taking the first steps to do so, primarily due to the allure of being able to make commits locally while working on stuff, but also to get a handle on these new-fangled distributed version control systems at last. By early 2012, I'd finally started developing a good feel for working with Git (*). So, when it was time to start setting up repositories for a number of projects at the start of the year for uni courses, Git was the natural choice (over SVN).

(*) TBH, the Git-Gui interface that's bundled with msysgit is actually really good once you finally understand the way that you're supposed to work with the beast. In fact, apart from it's ugly Tcl/Tk looks, IMO it's currently the best frontend I've worked with so far.

The main window provides exactly what you need for everyday committing/change reviewing, and allows you to define helper tools for things you do often. Many people often don't really give it credit for this flexibility and clarity of purpose, but once you've seriously used it, everything else looks lame and twisted (like someone who doesn't truly understand the benefits of such workflows trying to graft one over from other VCS's).

In my case, I've added custom commands providing access to "pull" but also to simplify the pushing/pulling from online master directories - e.g. when working with my Gitorious Blender repo/branches, those repositories were set to pull/be based on jesterKing's mirror, but they had to push to a different repo (since jesterKing's was read-only), and at one point, I also needed to be able to pull from sergof's repo too.

 The command-line comes in second, though it's not something I'd recommend that you start with as it offers very little visibility into what's going on at a glance if you don't have the right mental pictures of what's going on to start with.

By that point, the advantages of using a DVCS over SVN had already become "must have" features. Things like being able to actually hack on things in branches (and merge changes back in, without long frustrating and error-prone witchcraft most of the time), siphon immature ideas or wrong turns into side branches for archival purposes (or simply just to lob off the offending commits completely), and being able to quickly fix idiotic-typos made in a just-made commit. For instance, the ability to use branches to test out several different approaches to speeding up an algorithm, quickly swapping between those code-bases without confusing yourself, and then being able to develop upon those while keeping the "progression lineage" (that is also preserved in its natural form) was priceless (NOTE: this was an actual example for a sudoku solver I worked on). Another example was the ability to safely apply "replace all" batch fixes, and then be able to sift through the damage and only approve/remove changes as necessary (thanks to the ability to partially stage/unstage individual line-by-line changes in the changed files instead of being restricted to all or nothing). 

Anyways, despite my best efforts at the time, I could not for the life of me figure out how to access the Git repositories I'd created on my Uni Linux account via SSH so that I could directly sync them with my laptop. I tried various different URL's for doing this to no avail. Also, back then, most if not all posts sounded like you could only do it if you had some kind of special "git" ssh account on the server (which was obviously out of the question in this case).

Instead, at the time, I ended up settling with using a third-party Git hosting service (originally Gitorious, but then Bitbucket later once I tired of the slowness/bugginess/publicness of Gitorious, whereas Bitbucket allowed for unlimited private repositories with a really nice hosting environment) as my "master" server, which I'd have to remember to sync to/from my Uni account and laptop. In some ways, this has benefits, especially for "important" projects (i.e. an offsite backup that's not located in the country!) or for those that may later have release value (it's just a click away - though you probably want to double-check and sanitise the repository first, to remove any embarrassing/confidential stuff that may have crept in).

Oh, and for one repository, I ended up going back to just using SVN for it as it was simpler to set up (and also due to the nature of the content to be held there), though by the end of the year, that decision was really coming back to haunt me, as the lack of some of the aforementioned features was really killing me by then everytime I had to work with that repository (e.g. at one point, I had a spotty internet connection for a day or two, and so I couldn't commit changes back, and ended up batching a whole bunch of changes together in one nasty big commit, partly obscuring the separate intentions of what I'd been trying to do). Gah!

---

Magic Commands
Anyways, here's finally the real meat of this post: this is how I got things working...

Grabbing a Repo from COSC Servers

$ git clone user@server:~/repos/project.git

That's it! Dunno why it was failing in the past, but somehow, once I did this, it all just worked. Now I can sync some of the "lesser" repos that I might create for small things that need syncing (while tracking history) without having to create a copy on a third-party server (and hence be bogged down by looking at it everytime I need to hunt down something that really matters there).

Cheers to http://www.mindfuzz.net/?p=250 for the tip!


Finding the SSH settings files on Windows
Unfortunately, my current SSH settings setup on my laptop is a bit "complicated" to say the least. That's because I've got several different SSH clients around, each for the separate VCS's who brought-along their own copies or systems, and some of which I've ended up tying together for various reasons. Perhaps it's not really the best position to be in, but oh well... somehow it all works out when I need it to XD

If you've been using SSH for long enough, eventually, there'll come a day when for whatever reason, the server gets an upgrade or whatever, and suddenly it needs a fresh batch of keys. Hence, you'll be forced to purge the old records so that operations work. However, the problem is knowing exactly what and/or where to do so...

From what I've found, it all boils down to:

1)  %HOME%\.ssh\known_hosts  
2)  %HOME%\AppData\Local\VirtualStore\Program Files\Git\.ssh\known_hosts

1 = Putty and/or TortoiseSVN
2 = Git

Hints:
- Remember to make the changes for both sets of keystores or else one or the other will fail, and you'll be left wondering for ages why, even after changing things, the problem still persists!
- The first time after clearing the keys (or perhaps on first usage), it's best to use commandline vs the Git-Gui interface, as it is necessary to provide some keyboard input to get things accepted that first time (which is difficult to do in the Git-Gui popups, which will instead exist with an error).