On Nuget, Git and unignoring packages

Git has a helpful ability to ignore certain files. When working on .net projects, you normally want to ignore your .suo file, bin and obj folders etc.

If you’re using the excellent GitExtensions it will even provide a default, reasonable .gitignore file for you.

Problem is, that while you want to ignore certain patterns in most of your project, generally you want none of those rules to apply to your nuget packages.

Everything in packages folder should be committed. Always. No exceptions.

To do that, you need to leverage a child .gitignore file.

Create a .gitignore file inside your packages folder and add the following line to it:


This tells Git to disregard any ignore rules of the parent file. Now all your packages will be committed completely, without missing any of their functionality.

Connector: Simple, zero friction Github –> AppHarbor integration

Recently to play with some new technology I came up with an idea to build an integration layer between Github and AppHarbor. What that means, is give you ability to work with your Github repository, reaping benefits of all of it’s VCS-centric features, and automatically, continuously deploy your code to AppHarbor.

The actual scenario I had in mind is to be able to use that for deployment of Open Source projects. AppHarbor is fantastic, no-headache deployment in the cloud, but Github is perfect for keeping and developing your code in the open, in social way. To have the cake and eat it too, Connector was born.


I hope you find it useful. it is free, use-at-your-own-risk-and-don’t-sue-me-if-something-breaks software. There’s still some work to be done, feature-wise and a whole lot of polishing but I decided to announce it early and get early feedback. If you have any suggestions, ideas or (gulp) bugs, let me know!

link: http://connector.apphb.com/

Hope that helps.

Simple guide to running Git server on Windows, in local network (kind of)

Last year I found myself in a sudden and quick need to set up working environment for a team of four, and as I like Git very much, I wanted to use it as our VCS. The problem was, we weren’t allowed to use any third party provider, so GitHub was off the table. As I searched the Internet there were a few guides to set up team Git environment on Windows, but they all seemed very complicated and time consuming. For our modest needs we experimented a little and came up with a solution that was very simple, didn’t require any additional software to be installed anywhere and worked like a charm.

Recently I used it again on my current engagement, and one of my colleagues suggested I should blog it, so here goes.

Ready, steady, go

The guide assumes you already have your local Git set up. For that, there are plenty of resources on the Internet, including my own blogpost about Windows Git tooling.

The entire tricks works like this – expose folder containing your shared Git repository as Windows network share.

Step one – bare git repository

There are two twists to the entire solution – one of them is – your shared repository needs to be initialized with –bare flag.


Step two – Windows share

Second step is to expose the folder with our newly created repository on the Windows share. You also use your standard Windows mechanisms to control and limit access to the folder (make sure you give the developers write access!).

Step three – Map the share as network drive

This step is perhaps not exactly necessary but I couldn’t get it to work otherwise, so here comes the second twist. In order for your developers to be able to access the shared folder via Git they need to map it as network drive.


Step four – Add remote repository in Git and code away

Last step is the standard Git procedure – every developer on your team needs to add the repository sitting under their newly created network drive as remote. Notice the use of “file:///” prefix in front of the mapped drive name.


Step five

That’s all. I hope you find it useful, and if you know a way to eliminate step three, let me know in the comments.