Setting Up 'git' on Windows? My Huge Increase in Traffic Says You Are...

Thanks to a couple links from other sites I've noticed that many Windows users are interested in accessing git repos. The current Windows git client allows for much of the standard git usage on Windows. However, there may be an even better option for Windows users.

Using Eclipse to Manage Gitosis

In my many stumblings with getting Windows to even speak with a git server I noticed that it would be much easier if I could manage my gitosis setup through Eclipse. Since I have Eclipse on the triplets (The PC, Ubuntu and Mac Mini) I would be able to add and administrate my projects and users from any computer. Since I managed to get the standard Windows git client to work once I generated, uploaded and added my public key to the gitosis repository I figured that it should be a snap to use Eclipse and the git plugin to manage the gitosis repository. Well, it was not a snap but once I figured out the issue it did seem fairly simple. The trick is that Windows doesn't seem to handle the public keys very well. So, while I thought I was good to go Eclipse has it's own SSH key management. So, once you generate the public/private key pair in Eclipse, add that to your gitosis repository (I chose a different user name for the standard and Eclipse Windows user ie 'username' and 'usernameeclipse'). This allows me to choose whichever method is most efficient at the time. Once those changes have been added, you should have access to the 'gitosis-admin' repo from Eclipse and can then manage the repository from there. Although it may not be needed in this instance, some of the more powerful features in git have not been added to the Eclipse plugin. Having all options available (like using git-gui) can make some complex operations easier outside of Eclipse for the time being.

Sharing git repositories with Gitosis on Ubuntu, Windows, and OSX using Eclipse and CLI

UPDATE: 8/2/2009 (Added additional information regarding Windows)

Even small web projects can gain a significant benefit in using a version control system. Many web projects are available using SVN, but an increasing number are turning to git for various benefits such as the ease of working with a distributed development team, easy branching and merging, hooks/scripts at important points (such as a pre-commit validation of structure or a post-commit database schema update script), support for submodules (a type of inline repository/mini-code-base if you will) and more.

I won't start with creating the repository and will assume you already have a server or host providing a repository location. So let's say that you've got yourself a server and some client machines where the clients have an ssh client, a version of git, and Eclipse. You also have your server running ssh, git and gitosis. The server doesn't need to have Eclipse (unless you're running a machine as both a git/gitosis server and your client workstation. The problem is, your client machines may be Windows, Mac or some flavor of Linux. So perhaps I want to assume different 'roles' as I work on different machines. Luckily I can use any of the systems, but if I want to include my friend the systems administrator who wants to use straight command line git, a graphics guru wants his OSX desktop apps and our handy frontend developer who needs some Windows (Either WinXP or Vista) tools. Isn't it nice that they're all making it easy on you? So, how can we make all the users happy, with the minimal amount of disruption possible in their desired workflow?

Everyone won't get their way, but the compromise to make it work allows everyone to push and pull from a central location. It's a foundation to build on. So what's our final goal? We need to be able to push to a central location from a Linux command line, Ubuntu let's say. We need to be able to use Eclipse (whether on a Mac, Ubuntu desktop, or Windows XP) to push and pull from a central repository. We won't worry about fancy stuff just yet. Let's focus on getting our code here, changing it and pushing it back.

I'm not currently aware of any Widows git/gitosis setups but if anyone out there knows of any let me know about them in the comments. So, from our Linux command line, we created a new git repository within gitosis. If you have already gone through a tutorial or two and managed to get gitosis up and running, then adding a new project should be a snap for you. We have added our entry in gitosis.conf, created the initial local repository and pushed it to the server and are now starting to add our users for the project. Here's where you can make everything go right, or get set up for a huge fail later. The biggest mistake you can make is to generate bad keys. Since we are administering this from a Linux command line, we know that this user is setup correctly. I'll cover the Windows instructions first as that seems to require the most configuration to work properly. From there, many instructions will be similar for both Mac/Linux users so reading through the Windows instructions can be helpful for Mac/Linux users too. Let's get our WinXP user set.

WinXP

Fire up Eclipse, then under Preferences (General -> Network Connections -> SSH2 and work under the "Generate Key" tab). It is extremely important that you make triple sure you generate it correctly here. Once you have generated the key, send the public key generated here to the gitosis admin and he'll add you to the both the keydir and to the project entry in gitosis.conf and then push it to the git server. As per the gitosis instructions, the key should be in the 'user.pub' format with 'user' being the name added to the gitosis.conf file under the project. Once the changes are pushed to the git server you should be able to use Eclipse and the Git plugin to import a git repository.

Importing a git repository in Eclipse

The sequence of steps seems quite important. Not performing an action in this exact order seems to break the imported repo. I'm not 100% sure why just yet. After installing the git plugin and restarting Eclipse, you should now be able to go to File -> Import and select 'git repository' From there simply use 'ssh://gituser@[192.168.1.X -or- somewhere.net]/repository.git' and hit 'Next'. It should show you a list of branches (or just master) and after clicking 'Next' you can choose if you want to import a project (I don't) and then 'Finish'.

From there immediately create a new project (I've found it helpful to match the repository and project name without an extension) and hit 'Next'. You should now see your project in Eclipse and our final step is that we only have to let Eclipse know that it's a git project you can share with other people. Yes, I agree it's redundant since we already told Eclipse we are importing from a git repository, but bear with me. Now just right-click on the project, select 'Team->Share' and then select 'git' from the list and that's it! Your project is imported and ready to use. You can now make changes and use the Team -> Commit and Team -> Push to change and share your changes.

There is a different git client available for Windows which has more advanced features than what the Eclipse plugin provides. You should install a program available on Google code called 'msysgit' which provides a handy way to browse the history of your repository. It also gives you a different interface to merge changes from the remote repository if Eclipse doesn't seem to work for you. If all you need is the basic features available in Eclipse then you should be fine without it. But since neither the Eclipse plugin nor msysgit have all the features you might want it's nice that they overlap and complement each other.

After you install msysgit you will have access to a right-click menu of 'git gui' or 'git bash'. So if you browse to your workspace and use git-gui on your Eclipse project directory you can use more commands available from the git-gui interface. Especially with git, you should ALWAYS, before you commit your changes, pull any changes from the branch where you are pushing to. If you do not, this can lead to a 'non-fastforward' situation where you can't push your changes to the repository because the code in the repository has changed since the last time you pulled from it. The git-gui interface for fetching those changes makes it easy to see what's changed since then in your pull. Once you successfully merge your changes in git-gui, you can flip back to Eclipse and refresh the directory and see your new changes.

Now comes the trick which can cause you many hours of pain. Due to some weird issue with Windows and SSH key management, it appears to treat Eclipse and the 'git-gui' separately with regards to keys. So to skirt the issue you must generate a second key from within git-gui (or through git-bash if you are already comfortable with generating a key using a command-line interface) and upload THAT to the git/gitosis server as well. Yes, I agree it's annoying but I haven't found a way around it just yet. Since I occasionally use both programs, I need the repository to accept changes from either program. You can use the same passphrase for both keys, but you'll need to setup two users to make it happen. I have used a 'user-e' and a 'user-g' scheme where the -e represents the Eclipse key user and the -g represents the git-gui user.

Mac OSX

Luckily here we're much better off with regards to key management. Just as before, you can generate the key from within Eclipse, or, in terminal using the 'ssh-keygen -t rsa' command works. But in this case we only need to do it once. The reason is that the key handling is much better here and regardless of where we generate the key only that one will be used when you hand it off to the gitosis admin whether you are in Eclipse or using terminal. Again, this key.pub gets uploaded to the gitosis admin and pushed to the git host. From there, you can use Eclipse as described above (Import->Create New Project->Share As 'git') or there are a few other git tools for OSX you can use that I'll leave you to Google. So as before: Import a git repository from the location you provide. Create a new project with the same name. Share the project as a git repository. Pull, make changes, push. Again, since the tools aren't implemented perfectly, you may need more advanced tools available with other git clients. Though, for many projects all you need is Eclipse, git, and you're good to go.

Ubuntu Desktop

Install Eclipse + git plugin. Generate key with 'ssh-keygen -t rsa' + upload to gitosis admin. Pull from and push to the repository you provide. Finally, something easy. :)


Goals Check

So let's recap. Our git server has repositories managed by gitosis accessed from a Linux command line. We can also access our new repository in Eclipse from a Linux, OSX, and Windows desktop environment. Check.

One final test is let's make sure that a remote client can also access the repository. Up to this point you may have been using a local hostname for the server, or maybe the IP address. Maybe that's all you need for a local network. Perhaps your friends are across the world and don't want to have to remember your IP address but rather a simple domain name. If you're behind a firewall (a Linksys home router maybe...) you'll need to log into the admin panel for the router and make sure that port 22 is open and pointing to the correct machine. Grab a free domain name from DynDns and point it at your home router. You should now be able to pull from 'ssh://gituser@free.dyndns.net/repository.git' as long as your keys have been correctly generated and installed correctly by the gitosis admin.

Questions? Problems? Let me know.

How to 'git' Git - A tutorial for creating, using and maintaining repositories for DVCS (distibuted version control systems) for web applications

After many hours of struggling...I think I'm close. I almost understand 'git'. No master for sure, but I can get through the basics required to maintain a web application. Many thanks to the people on IRC who humored me for far too long.

Here's Why You Use git

There are many different version control systems out there. Some are better suited to a specific language or platform, while others are more flexible. It's a simple case of the best tool for the job. If you are a single person and want to incorporate version control into your workflow then git will work well for you as it allows you to have the main repository local to you and then the ability to share later if you want. If you are a team, then allowing developers to work locally and push clean changes to a central repository may be how you want to operate. The nice thing about git is it allows you to be flexible. You can start with a big group, a few guys or just one person. Depending on the working environment perhaps a central repository system such as SVN may be appropriate as well. Just make sure you choose the right tool for the job.

Now here's how to start using git in about 10 lines (Quick Start)

On remote (where you want the repository to be maintained but won't be worked on):
1.) mkdir repository-name.git
2.) cd repository-name.git
3.) git --bare init

On local machine (where you will be working on):
1.) mkdir repository-name.git
2.) cd repository-name.git
3.) git init
4.) touch some.kindof.file
5.) git add some.kindof.file
6.) git commit -a -m "Added initial file. Maybe a readme or a project definition"
7.) git remote add origin (ip: git: ssh: or user@host:) (path/to/repo.git)
8.) git push origin master

That's it. Our repository is being held on the server and a copy is now in sync on our local machine. Now just start adding and altering files and try to remember "Commit early and often" so as each change can be rolled back. If you're just starting out, don't worry about taking up too much space by committing a good descriptive message with every small commit. There's a technique where you can 'squish' several commits into a single one and then cleanup the final message before pushing it to a remote branch. Now it's just a matter of checking out branches, pulling in remote changes often and then resubmitting quality changes. Merging will be needed and there's some other nifty techniques and commands we won't explore.

How about something harder?

Let's import something from a SVN repository using git-svn. I'll be demonstrating with the Magento e-commerce application. You can run this on the server or your local client. I might suggest the server if it's faster than your local PC. We'll start with:


mkdir magentosvn.git
cd magentosvn.git
git svn init http://svn.magentocommerce.com/source/branches/1.3
git svn fetch (Go get a cup of coffee, it could take a while depending on size)


That's it again. See how simple this can be? Now you're free to check out branches, review history and do what you do. I may cover pushing back to the SVN repository some other time. Now just clone the repository and you've got yourself an e-commerce application.

Having problems? Having success? Let me know if this was helpful by leaving a comment.

Thanks to the following pages:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
http://git.or.cz/gitwiki/GitCheatSheet
http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
http://toolmantim.com/articles/setting_up_a_new_remote_git_repository
http://wiki.sourcemage.org/Git_Guide
http://thelucid.com/2008/12/02/git-setting-up-a-remote-repository-and-doing-an-initial-push/
http://cworth.org/hgbook-git/tour/

Gitosis Setup Help
http://www.simplicidade.org/notes/archives/2008/09/installing_gito.html

Git-SVN Pull, Merge, or Rebase
http://stackoverflow.com/questions/582348/using-git-svn-pull-merge-or-rebase

Next Gen iPhone Rumors - Wired.com Round-Up Post & Four Wanted Features

Wired has posted an article (Everything We’ve Heard About the Next iPhone) with next gen iPhone rumors. Rather than rehash everything they've said and just repeat the article with my predictions, or spout off more stuff like I did for the iTablet rumors, I'd rather list the items I'd like to see on the next gen devices, iPhone and iPod Touch included.

1.) Faster processors, more RAM, more storage.

-These should be fairly standard in an incremental upgrade. One of the drawbacks is that powerful processors use more power so battery life might suffer. It would certainly allow for increased capabilities for iApps.

2.) Improved Audio/Video capabilities.

-The iPhone should get video recording features as well as a front facing camera. The iPod Touch should also get these features in addition to a microphone. It's one of the few features that disappointed me regarding the iPod Touch. So many times I wish I could have said 'Next!' into a microphone to advance the track playing rather than pull it out of my pocket.

3.) Even better screen

-I was very impressed with the quality of the screen on the iPod Touch. I doubt that it's high up on the list of features since the current models perform just fine. I'd still like to see some newer technology in the screen such as OLED and an even higher resolution. I can't complain about the current resolution, but I can certainly want more.

4.) Longer battery life

-Again, I can't complain about the battery life, with the exception of using juice -sucking Wi-Fi, but a longer lasting battery wouldn't hurt. I would even be ok with adding another couple grams to the device weight, or even adding a little bit to the thickness to obtain it.


It seems to come down to the old mantra of 'Bigger, Better, Faster, More' for updates. What do you think? What would you like to see? Do you think a compass is a worthwhile addition to the iPhone? If you've got an iPhone, what do you want from it, if you don't, what's holding you back from getting an iPhone/iPod Touch?

Magento e-commerce

Most days you'll find me in a few places related to the Magento e-commerce platform. You'll likely find me in the #magento channel on the 'freenode' server in IRC. I'm usually trying to help people with the issues they're having and offer help or answer questions for those thinking about getting into programming or customizing Magento. You can also find me on LinkedIn and answering questions about e-commerce and other web design topics.

There's several features that I like about Magento and I'm looking forward to sharing all that information with the readers here. I'm working on a fairly large tutorial for taking the current version of Magento from SVN and moving it to GIT for version control. I've also got a wiki in the works if anyone wants to help out by adding articles to it or reviewing it prior to launch.