Start a Windows MPLAB X Project by Cloning a Git Repo

MPLAB X includes great built-in support for Git but it assumes projects are created first from within MPLAB X (File > New Project ) before managing them using Git. This doesn’t help if you’re starting by cloning a remote repo.

I’m using MPLAB X on Windows. The standard Git install for Windows from the Git project includes Git GUI, a basic Git client GUI app. I’ll use Git GUI to clone the remote repo, and then use MPLAB X’s built-in Git client for everything else.

Start Git GUI

and select Clone Existing Repository.

Clone the remote master repository locally (the master repo for me is on a Windows network drive).

When the remote repo has been cloned, Git GUI will show the current status of the new local repository – which should show no modified files (i.e. no files either staged or unstaged).

To confirm the repository was cloned correctly, you can check the commit history by accessing menu Repository > Visualize master’s History.

Now we can open the cloned local repo using MPLAB X.

Git is primarily accessed using a project’s context menu from the Project window.

However, be aware there are a few Git commands under the Team menu, including a Repository Browser that isn’t available from the project context menu.

Try accessing Show History for the project (you will need to click “Search” in the Show History view that opens).

Now I’ll ready to start hacking on the source. I’ll keep it simple and just add some TODO’s to the README.txt file. Notice how the editor shows my changes compared to the last commit in real-time!

When I’m ready to commit my changes, I can commit just the modified README.txt file,

or I can commit all modified files in the project.

To push a local commit back to the upstream origin repo, use the general-purpose Remote > Push… selection from the Project context menu.

Origin is the only remote repo configured in the local clone, so it should be indicated automatically in the Push to Remote Repository wizard.

There, all done! Wasn’t that easy?

I didn’t do show it here, but standard practice is to always Pull from the upstream repo (e.g. origin) before you try pushing code. If someone has pushed code to the master repo since your last pull (or clone), you’ll need to merge their changes from the master repo into your local repo first, then push your combined changes back to the upstream repo.

Configuring Git

I needed to configure Git on a new server recently (no GUI), and couldn’t remember my typical configuration.

Disable Output Color-Coding

Many developers can’t live without color-coded command-line output, but you may find (as I do) that less than perfect color vision combined with high ambient lighting and some screen glare results in a display that is essentially incompressible. To disable color-coded command line output from Git:

$ git config --global color.ui false
$ git config --global color.diff false
$ git config --global color.status false
$ git config --global color.branch false
$ git config --global color.interactive false

Ignore File-Mode Changes

Git may report that executable files (e.g. shell scripts) have been modified based on differences in file mode interpretation between Unix and Windows systems. If the mode of a file is set to executable and committed to a Git repository in a Unix environment, and then the repository cloned into a Windows environment, the file will be reported by Git in Windows as having been modified – based on its mode. This is the result of subtle differences between a Unix file system and a Windows file system. Committing the “modified” file in Windows and pushing the repository changes back to the Unix repository will result in the file not being executable in Unix (until its file mode is set back to executable).

If this is an issue for you, set your Windows global Git config (~/.gitconfig) to ignore file mode changes (but first, check that your global configuration will not be overridden by a repository configuration).

Check your global and local configs:

$ git config --global core.filemode
$ cd gitrepo
$ git config core.filemode

Set configuration to ignore file mode changes:

$ git config --global core.filemode false
$ cd gitrepo
$ git config core.filemode false

Git on Windows

Update 2012-09-14. Install Git-Extensions – nothing else needed! (msysgit and kdiff3 are included in the install).

I’ve been happily using Mercurial for personal projects (the cli on Unix and TortoiseHg on Windows), but avoiding Git has been like holding back the sea. The dike finally broke on Saturday, when Ivo Jansch announced he was forking ATK (the incredibly efficient PHP web app RAD framework he had created while at iBuildings), and I could see Git was going to become a much more significant part of my development flow (more on this to come I hope).

Refreshing my memory of Windows Git clients, it seem the main choices are:

Git for Windows (aka git-gui) is the official Windows client. I’ve tried it before and it works, although not as polished as TortoiseHg.

SmartGit, although commercial software, is interesting because it supports both Git and Mercurial, and a review recommended SmartGit for new Git users. The review also said SmartGit is “free for personal use”, but my interpretation of the free non-commercial license is that including SmartGit in any revenue-generating activity is not allowed. In other words, I don’t believe the license permits you to use SmartGit for managing your open-source project if you are also selling services related to the project. That said, I’m going to try out SmartGit first – if only to get my Git-legs back.

TortoiseGit is a port of TortoiseSVN for Git, and I suspect what I will eventually be using –  unless SmartGit is so impressive that I’m willing to part with $80 for a single-user commercial license.

I’ll update you after spending a couple weeks with SmartGit and TortoiseGit.