The keynote today was from Jeff Atwood of Coding Horror and Stack Overflow fame. I’ve been reading Coding Horror for ages and listened to a lot of the Stack Overflow podcasts so this was just a rehash for me. But probably interesting if you hadn’t heard it before.

Agile Testing: Advanced Topics

Janet Gregory (@janetgregoryca) started her session by talking about the Agile Testing book she had written together with Lisa Crispin 3 years ago. Janet reflected that the book has held up pretty well but that she wanted this session to be about what has changed in the last 3 years; a of summary of the latest ideas about Agile testing.

The first topic was Feature Acceptance; when you are not meeting your customers’ expectations you can try to build the features that matter, that make the customer happy. Janet had a great jigsaw puzzle story to illustrate this point. She had taken a jigsaw puzzle with her to build while supervising kids at a summer camp, and didn’t get as much time as she had planned to finish it. But because she chose to build her favourite parts of the picture on the jigsaw first, she felt pretty happy about it anyway. She had completed enough to see the soul of picture and that she hadn’t completed all the boring blue sky bits didn’t really matter.

Janet told another story that also intrigued me. She bought a toy pirate ship for her team and told them it was a symbol for their legacy codebase. The team then proceeded to mess up the ship with Play-doh and markers until it looked as ugly as their codebase. Then after every sprint they tidied up the ship a bit just like they were tidying up their code. It’s amazing how the human brain works but this physical stuff really helps with motivation.

All-in-all a nice little summary of Agile Testing.

Domain Models and Composite Applications

Udi Dahan (@udidahan), one of the lead developers on NServiceBus and a DDD expert, had a session for us DDD beginners. First he described a traditional domain model, just like the ones all of us have seen in our projects. These models typically have huge, interconnected database schemas and are really hard to change and understand. Udi recommended a mind shift to get around this. Don’t focus on the entities, focus on the field instead.

He used a really good example to show this, the customer entity. What is a customer in business terms? Sales works with leads, as soon as they have sold their product, then they move onto the next lead. So they don’t use the word customer and don’t really work with or care about the customer. Accounting sees the customer as an account, so a customer isn’t a term they use either. Not even Customer Support sees the customer in the same way as the typical customer entity in a model. So it is basically just us developers that believe there is such thing called a customer due to us focussing on entities (nouns) instead of fields.

The point being that we should not have one model that fits everything. We should have different models for different fields. When we do this then we can split up the database into independent mini-databases. These bounded contexts (DDD word) communicate with each other by sending the id of the aggregate root and not by sharing state. This makes it possible to have a mixture of relational and NoSql databases. The motto being use the right tool for the job.

Udi did a great job with this presentation. Recommended for watching when the videos come out.

Credit Crunch Code

Gary Short (@garyshort) had it tough being both heckled by Mark Rendle and a baby (the baby seemed to quite enjoy the session) while doing this session on Technical Debt. But he managed it so well, I started wondering if he’d also been a stand-up comedian (as Mark was). Before going into this session I wasn’t sure if I’d learn anything new about Technical Debt. But I did!

The first interesting new concept Gary talked about was interest on Technical Debt. Once Technical Debt is incurred it also accrues interest. He defined interest in these terms:

• The time is takes to get back up to speed on the code where the Technical Debt was incurred
• The cost of the damage to your brand due to Technical Debt
• Possible loss of market share
• Low morale in the team

Then he took this even further with a mathematical formula for calculating Technical Debt. This could be used to put an actual number (in kronor, euros or dollars) on the value of your Technical Debt.

He ran out of time at the end and had to skip a bunch of slides but he did it in such an entertaining way that it didn’t affect the quality of the session. I had fun at this one.

Transforming Data into Pixels: Visualization with Canvas and Coffeescript

Trevor Burnham did a live coding session on using Canvas in HTML 5 to visualize data. This wasn’t what I thought it would be. It was more a presentation of Coffeescript than HTML 5. Trevor did some low level Canvas rendering of data points (with x and y values) which could eventually be a data visualization tool.

Unfortunately, compared to Christian Johansen’s TDD Javascript session this was distinctly unimpressive. Trevor struggled a bit with the live coding and it did not showcase Coffeescript in a good way.

Patterns of Effective Delivery

This was a follow up to Dan North’s keynote yesterday. Dan presented some new patterns that he is currently figuring out. First Dan defined the three words Pattern, Effective and Delivery. The definition of Effective was extremely interesting. Effective only has meaning in a context, it depends on what you are optimising for. Today, quite a lot of us optimise for security in our processes. Processes like Scrum optimise for teachability. This is a very deep question, what are you optimising for in your current project?

Dan then presented a bunch of new patterns that developers could use depending on what they are optimising for. I don’t know what to make of these really. I’ll have to let them sink in and try think about them for myself. Some of them are really controversial and go against the current thinking in the Agile community. This session made me feel like a novice again. I don’t think I can use most of these patterns, I am just not good enough yet to judge if they have value. Unbelievably thought provoking, totally wrecked my head as we say in Ireland. Great way to end Öredev really. My cheese is moved.

Keynote

Dan North delivered the keynote today with the title Embracing Uncertainty (the Hardest Pattern of All). I was really looking forward to this as I’d seen some of Dans’ talks on InfoQ before and they were all really good and really thought provoking. The theme was uncertainty and how we as humans will do almost anything to avoid it. To get a really good summary of the keynote check out Gojko Adzic’s review.

The Agile Manifesto is all about embracing change (uncertainty) but we are not living up to it. Process and tools are still winning over individuals and interactions. It’s the same thing with the other principles in the manifesto. It is so hard to fight against human nature and to accept that some things are uncertain, that some risks are unforeseeable, that some tasks cannot be estimated. It is so easy to fall back into waterfall even if we say we are doing Agile/Scrum/Kanban. So true, so deep. Dan has a solution with Deliberate Discovery, not an easy solution by any means and a tough sell to customers and colleagues. A brilliant keynote that will stay with me for a long time.

Domain Driven Design and Agile

This was one of my dips today. A session by Tomas Karlsson from FRA (Sweden’s version of the NSA) on DDD and Scrum that just never grabbed me. As everything from FRA is classified, he couldn’t use real examples from their domain models and instead used a sample model. This really lessened the impact of his talk.

He had a few interesting points about mixing Scrum and DDD and how they sometimes clash. Both in interactions with other teams and when refactoring the domain model. And he had neat little whirlpool model of development for the domain model. First Harvest requirement –> Model them –> do a Code Probe to test the model’s api –> challenge the Model with a new scenario. Rinse, repeat.

Maybe I am not in the target audience for this type of session but it I didn’t get much out of this. Don’t recommend watching this on video.

Sleeping with the Enemy

Another real high with Gojko Adzic. All about trust issues and tearing down the artificial walls between developers and testers. He talked about how mistrust manifests itself in the development process through processes like Requirement Signoffs and Change Requests. Alibi generators – ways to point the finger at someone else and say it wasn’t my fault. Gojko has worked with some companies that haven’t had a bug in months/years and none of them use these processes.

At this point Gojko challenged the audience with this question: Who should be responsible for functional tests; programmers or testers? There were some testers in the audience that voted testers and some that tried to answer both. The right answer according to Gojko (and I agree) is programmers. Tear down the walls, programmers have to be able to test and they have to write the functional tests. Testing and quality should be a part of the process from the first line of code to the last. Testers should be more like test architects advising programmers on what they should be testing and instead focussing on high value activities like usability and exploratory testing. Check this out when the videos for Öredev are released. Compulsory viewing for all programmers.

Zen and the Art of Programming

Mark Rendle (@markrendle)  did a reading of Zen and the Art of Motorcycle Maintenance and applied it to software development. A deep, philosophical talk that tried to get to the core of why we develop software and how we should practise it. About being a professional and producing quality. He used the concept of Gumption (get up and go, motivation) from the book and how not to lose it. There are a list of gumption traps, some internal and some external, that we all experience at some time or other.

For example, boredom is one I have personally fought against a few times. You’re doing yet another <insert boring project type here> and just can’t wait to get it done so that you go home. In to work at 9 and out at 5, and leaving your brain at home. Mark then gave the advice to think of this in a different way. Put yourself in the user’s shoes, they are going to be using this system for 8 hours a day and if you don’t do the best job you can then you are ruining a third of their life. So be a professional and make the system as user-friendly and brilliant as you can. You’ll be happier in the long run this way.

Mark was previously a stand-up comedian and he timed it perfectly with his line when someone’s mobile started ringing during his closing. I can’t (or don’t want to) quote it here but that alone makes it worth watching this session on video. Recommended.

Cloud First Services

Marc Mercuri from Microsoft did a session on the cloud. I really don’t have anything (or anything constructive) to say about this. The worst session I have been at by far.

How to get productive in a project in 24 hours

Greg Young started the session by explaining why he was wearing a Celine Dion t-shirt. A bet is a bet and he keeps his promises. This was yet another tremendous (I have to find some more superlatives for Friday) talk. He explained his tricks and techniques to get going fast when consulting for a new customer.

The first trick, find the bug hive in the code of the customer’s system. By analyzing the source control history to find the places in the code that change frequently due to bug fixes. Valuable information to kick-start interesting conversations with your customer.

The next tip was to use Continuous Integration even if your customer doesn’t. Install Teamcity locally and you’ll see when your fellow developers break the build.

After that Greg showed us how to do a quick dive into an unfamiliar codebase with NDepend. Find cycles in the dependencies, examine the coupling of classes and for things like cyclomatic complexity. NDepend has its own query language where you can query the code to find methods that have more than 8 parameters or a lot of coupling for example.

Greg did a demo of Mighty Moose (Continuous Tests) his own product for continuous testing and code analysis. I’m beta testing this at the moment so that will be a future blog post (I promise!).

I’m skipping a bit here as there were a lot of valuable nuggets in this talk. This was a fantastic finish to a great day. Thanks again Active Solution for sending me!

All the sessions were good but I think my favourite session was Christian Johansen’s session on Test-driven Javascript (see review below).

So here is my summary in chronological order of all the sessions I attended.

C# 5: Async 101

Jon Skeet investigated the new async feature keywords coming in .NET 5. He did this by using following the spec for .NET 5 and implementing it himself using .NET 4. Impressively geeky. Check out his blog series describing his EduAsync project. Jon is very English in a Black Adder/Monty Python fashion which when combined with the geekiness of deep-diving into how the C# compiler works, made for a strange and interesting session.

SproutCore

Yehuda Katz, a core committer on the jQuery, Ruby on Rails and SproutCore projects, gave an introduction on just SproutCore. SproutCore is a Javascript MVC framework and a competitor to projects such as Backbone and KnockOut.js. Yehuda was pretty low-key and took the programming approach to showing off SproutCore. He had a really cool slide deck build with SproutCore which had an inbuilt console for live coding of SproutCore examples. And this, more than what he said, really showcased SproutCore. It builds on bindings to SproutCore objects or raw Javascript objects which make it really easy to make views update automatically. I could definitely see the benefits and will probably be using this or one of the other similar projects in the near future.

Resty Galore

I follow Sebastien Lambla (@serialseb ) on Twitter and chose to go this session because I was intrigued by this quote “Now, time to take pictures of that unicorn…” at 3 o’clock at night. I felt I couldn’t miss REST combined with unicorns and it was even better than I imagined. Sebastien used a secret agent unicorn named Resty Galore to illustrate links and forms in REST. Resty Galore had a mission to get to Malmö from Paris implemented as a series of http requests and responses. The first implementation was very procedural and rigid so Sebastien proceeded to introduce links and forms to reduce coupling in the workflow. At the beginning of the session I was wondering how would I ever apply this in my real life projects but by the end I had a few ideas about where I could use it. Any project with a lot of jQuery ajax calls and callbacks could potentially reap benefits of this approach. Intriguing is the right word here. More investigation required on my part.

Building mobile web apps using ASP.NET MVC 4, HTML 5 and jQuery Mobile

Phil Haack from the ASP.NET MVC team at Microsoft presented on the new mobile features coming in ASP.NET MVC 4. He started with Adaptive Rendering of current web pages so that they look better on mobile devices. MVC 4 will have a new default template which by using CSS 3 will change the layout automatically when the viewing device’s screen  is narrower than 850 pixels. Next up was a new DisplayMode features with which you can create pages specifically for a mobile device i.e. Iphone or Android. Phil then showed some jQuery Mobile stuff which is very interesting and feels like it will be how I get started with mobile development. And then lastly he showed off some of the new HTML 5 offline capabilities of jQuery Mobile. See this website here, connect once and then go offline to test it yourself!

Test Driving Javascript

Christian Johansen from Gitorious showed off some mad Javascript skills at this session. The programmer in me was very impressed. He built a jQuery plugin for autocomplete of a search for film database using TDD. Using js-test-driver, a unit testing framework, and sinon, a mocking framework, Christian used a fine-grained Test Driven approach to coding the plugin. He started with one large functional test that failed and then wrote around 10 unit tests to drive the design. And the revelation was that the process was exactly the same as using TDD in any other language. He used constructor injection to get rid of a jQuery ajax dependency in a class and he used sinon to stub out the ajax calls and to stub out the timing issues. I will be buying his new Test-Driven Javascript Development book. js-test-driver works well with Continuous Integration servers so no excuses; it’s time for me to TDD my Javascript as well.

Node.js

The last session of the day was about Node with Felix Geisendörfer, one of the core committers. It was a nice little introduction to Node where Felix showed off the various killer features of Node; Websockets, proxying data streams and parallelizing I/O and more. It has just been ported to Windows and the integration with IIS has begun so I will probably be using this sometime in the future. But not this year, so this is one technology that I’ll look at again when it is a bit more established on the Windows platform.

I will be blogging more about the sessions that I have attended later on this evening. See you then.

I used FluentMigrator as the example in my previous post and it was while creating the second package for FluentMigrator that I ran into a ‘feature’ of Nuget.

We had decided to divide the FluentMigrator package into two packages, the main core package and a new FluentMigrator.Tools package. FluentMigrator.Tools contains all the extra dlls that we didn’t want to put in the core package. Basically, there are four versions of the tools directory, one for each supported .NET version and per platform (.NET 3.5 and 4.0, x86 and x64). The idea is that if you need the x86 3.5 version of the migration runners then the core package is sufficient otherwise you need to fetch the FluentMigrator.Tools Nuget package.

The core package has a lib directory which contains the FluentMigrator dll. So I created a dependency on the core package in the Tools package so that when you download the Tools package from Nuget it also downloads the core package. This meant that the Tools package only contained a tools directory at the root, no lib and no content directory.

Side Note on how to test your Nuget package

To test your newly created Nuget package (always a good idea!) point your Nuget source in Visual Studio to your nupkg file. In Visual Studio 2010 go to Tools->Library Package Manager->Package Manager Settings then choose Package Sources in the left hand menu and add the directory which contains the nupkg file to be tested. Then when adding a package from the Package Manager Console, in the Package Source dropdown menu to the upper left you should have two choices now; Nuget official package source and your new test source. So choose your test source and install-package NameOfYourPackage and test it out.

To the heart of the matter

While testing the Tools package in the Package Manager Console I got the following incomprehensible error:

External packages cannot depend on packages that target projects

Steve Sanderson ran into this problem first and filed an issue on Codeplex in which he also mentions a workaround (Thank you Steve!). The reason for this error is that my new FluentMigrator.Tools package only contains a tools directory and no content or lib directory and Nuget has decided that it therefore may not be dependent on a package that does contain a lib or content directory.

The solution is a big, fat hack. Add a content directory with a dummy text file and then use a powershell script to remove it from the target project after you have installed the Nuget package.

Diving into PowerShell

At this stage you will want to have the Nuget documentation open so that you check out the different conventions around powershell and Nuget. I created a text file named InstallationDummyFile.txt and placed it in the content directory and a powershell file named install.ps1 and placed it in the root of the tools directory. install.ps1 looks like this:

param($installPath, $toolsPath, $package, $project)

$project.ProjectItems | ForEach { if ($_.Name -eq "InstallationDummyFile.txt") { $_.Remove() } }
$projectPath = Split-Path $project.FullName -Parent
Join-Path $projectPath "InstallationDummyFile.txt" | Remove-Item

It does two things:

• Removes the reference to InstallationDummyFile.txt from the project by looping through ProjectItems until it finds the text file.
• Deletes the InstallationDummyFile.txt file. First I get the path to the project file and store it in $projectPath and create a new path by joining it with the file name and then remove it from the project directory.

I am a total beginner when it comes to powershell so this was a bit of a struggle (and maybe will be for others?). The above calls are pipelines and start on the left with a bar (|) separating the different stages. E.g. The Join-Path function takes in two parameters and returns a new path to the text file, this is then passed on the next stage in the pipeline as a parameter. Remove-Item takes in the newly generated path as a parameter and deletes the file. Read the Nuget documentation for more info on the parameters passed in on the first line.

The Result

Now when you install the Tools package it first downloads its dependency, the core package, and adds a reference to the FluentMigrator dll in the target project. As the Tools package now has a content file, Nuget no longer classes it as an “external package”. Next Nuget installs the Tools package in the packages directory alongside the core package and calls install.ps1. This removes the dummy file from the project (both as a reference and by physically deleting the file from the project folder) and now there is no incriminating evidence left of us fooling Nuget. When creating my Rake script to run migrations, I can now refer to the console runner in the FluentMigrator.Tools directory in the Nuget package directory. Mission accomplished.

Related articles

• Creating Nuget packages with Rake and Albacore (danlimerick.wordpress.com)

I helped to change FluentMigrator’s packaging script to create a Nuget package a while ago, so I’ll use that to illustrate how to create a Nuget package with Rake and Albacore.

All Nuget packages need a nuspec file and there are two ways to script this. The first way is to just create a nuspec file manually and then update the version with the build script. Nancy uses this approach, see here. They parse the nuspec files with an XML parser to find the right nodes, such as version, to update. Nancy has a lot of packages so they search after nuspec files and create a package when they find one. With FluentMigrator we only have two packages so I used Albacore and the Nuspec task to create the nuspec file:

desc "create the FluentMigrator nuspec file"
  nuspec :create_spec do |nuspec|
     version = "#{ENV['version']}"

     nuspec.id = "FluentMigrator"
     nuspec.version = version.length == 7 ? version : FLUENTMIGRATOR_VERSION
     nuspec.authors = "Josh Coffman"
     nuspec.owners = "Sean Chambers"
     nuspec.description = "FluentMigrator description which is really long."
     nuspec.title = "Fluent Migrator"
     nuspec.language = "en-US"
     nuspec.projectUrl = "https://github.com/schambers/fluentmigrator/wiki/"
     nuspec.working_directory = "packages/FluentMigrator"
     nuspec.output_file = "FluentMigrator.nuspec"
  end

The only bit of logic here is for setting the version. There is a default version defined as constant but this can be overwritten by passing in a command line parameter.

FluentMigrator has a working directory for packaging where I copied in the files to be included in the Nuget package. Nuget uses conventions for the directory names in the working directory. The three conventions are:

1. libfor the assembly references to be installed into the target project,
2. toolsfor the command line tools and powershell scripts and
3. content for files that are copied into the root of the target project.

The main FluentMigrator package only uses lib and tools. Lib contains two subdirectories one for .NET 3.5 and one for 4.0. So the FluentMigrator dlls are copied into the appropriate lib subdirectories, the .NET 3.5 dll into lib\35 and the 4.0 dll into lib\40. Into the tools directory go all the different runners: the command line runner, the MSBuild runner and the Nant runner as well as all the dlls for the supported sql providers.

Then you just need to run the Nuget command line and call the pack command to create a nupkg file:

def nuget_pack(base_folder, nuspec_path)
    cmd = Exec.new
    output = 'nuget/'
    cmd.command = 'tools/NuGet.exe'
    cmd.parameters = "pack #{nuspec_path} -basepath #{base_folder} -outputdirectory #{output}"
    cmd.execute
  end

There is an Albacore task for this but I’ve gone with the Exec task instead here.  And this is called like this:

nuget_pack('packages/FluentMigrator/', 'packages/FluentMigrator/FluentMigrator.nuspec')

So to recap; the script creates a nuspec file, copies in the relevant files into the convention based working directory and then finally calls NuGet.exe with the pack command to create a Nuget package.

Pretty easy so far, it did get a bit more complicated building the second FluentMigrator package that is dependent on the first package. But I’ll leave that for another post.

Introduction

The Art of Unit Testing aims to teach developers how to write maintainable, readable and trustworthy unit tests. The author Roy Osherove has recently moved over to the Ruby community but is well-known in the .NET world for his TDD courses and TDD katas. He previously worked at TypeMock as Chief Architect so he lived and breathed unit tests for a few years.

This book is not what I had expected after reading all the online reviews. It is most definitely a beginner’s book, a book for someone just starting out with TDD. The first two books I read when getting started with TDD were Working Effectively with Legacy Code by Michael Feathers and Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. The Art of Unit Testing refers heavily to them and I would describe it as an introduction to unit testing. I noticed that The Art of Unit Testing placed above them on Jurgen Appelo’s Top 100 Agile Books list and I do not understand that to be honest. It would have been the perfect text for me during the first month of beginning TDD but feels mostly redundant after reading the two afore mentioned books.

The Meat of the Book

The Art of Unit Testing is well-written and easy to read, I flew through it in a few sessions. The first three chapters are a very basic introduction to unit testing. It gets a bit more interesting after that with nice, clear explanations of stubbing and mocking in chapters 4 to 6. Chapter 6 also contains a section on creating a test API that I really liked. It is the section of the book that I am most likely to reread later. Chapter 7 goes a bit deeper into writing tests and is the most interesting part of the book. It manages to gather together most of the good tips on unit testing that I have seen before e.g. enforcing test isolation, practising DRY even in your tests, keep setup code simple, avoiding overspecification. Chapter 8 is non-technical and is about getting your organisation to start unit testing. The rest of the book lists the various unit testing tools and frameworks available as well as the classic TDD books that you should read.

The parts that could be better

The lists of tools has not dated too well. The book is written in 2009 and a lot has changed in two years. Mocking frameworks like NSubstitute and FakeItEasy are not included and Rhino Mocks gets a lot of attention. The newer BDD tools like Specflow are also not included. Those sections will be near worthless in a couple of years time.

The last chapter on working with legacy code is very skimpy for a subject that is both huge and difficult. And generally, a lot more could have been written about unit testing. Nothing about Object Mothers or Test Builders (check out this article from Los Techies or read Growing Object-Oriented Software, Guided by Tests). Not much on GUI testing with Selenium or integration testing the database or the BDD-style of testing. When I write code I do not really separate writing production code and writing unit tests, the two go hand in hand. And this makes the book less valuable than a good book on TDD even if I can understand why the author chose to do so. There are a lot of .NET developers out there who know nothing about unit testing or TDD and something like GOOS would scare off most of them.

The formatting of the code samples is dreadful, the alignment is off in almost half of them. You can still read and understand them but it feels low quality. I am reading another Manning book at the moment and its formatting is fine so I cannot understand how that got in to the final version.

And the verdict is…

I would recommend The Art of Unit Testing for anyone getting started with writing unit tests but not if you have been doing TDD for a while and have already read some of the recommended texts on TDD. It’s a nice, smooth read and very easy to absorb but it is only about unit testing and not TDD (a minus for me) and there is almost nothing about writing testable code, a huge part of testing in my opinion.

There are two solutions to be able to copy/paste with the keyboard and directly with the mouse. The first is to use a different console, see Scott Hanselman’s post on Console2. I haven’t tried this yet so let me know in the comments if you use Console2 and can recommend it.

The other solution is to enable QuickEdit Mode under Options->Edit Options in the properties for the console. To open the Properties dialog, click the Git icon in the top left corner of the console and choose Properties in the menu.

Now you can select text with the mouse and right click to copy. Pasting is done by either right clicking with the mouse or pressing the Insert key. Still more awkward than using Ctrl-C and Crtl-V so maybe it is time to check out Console2.

Related articles

• Git for Windows tip: Setting shell aliases with msysgit (danlimerick.wordpress.com)
• Git for Windows tip: Setting $HOME and the startup directory (danlimerick.wordpress.com)
• Git for Windows tip: setting an editor (danlimerick.wordpress.com)
• Git for Window tip: Use P4Merge as mergetool (danlimerick.wordpress.com)

Setting $HOME

The first approach I tried was setting the $HOME environment variable. There are a couple different ways of doing this (like messing around with the etc/profile file) but easiest for me was using Windows’ environment variables as Git for Windows/msysgit has access to them. The Home directory for msysgit is set to the Windows environment variable %USERPROFILE%  if no $HOME variable exists. So just create a $HOME environment variable in Windows (see screenshot below)  and msysgit bash will use that as the default. Now you can use the command cd $HOME to go directly to your new home directory.

But msysgit still opens up in my user profile directory…

Unfortunately, this does not help with the startup directory problem. The solution is actually really simple. Right-click on the msysgit shortcut and in the Start in field, enter your desired startup directory. Easy if you know how.

Related articles

• Git for Windows tip: Setting shell aliases with msysgit (danlimerick.wordpress.com)
• Git for Windows tip: setting an editor (danlimerick.wordpress.com)
• Git for Window tip: Use P4Merge as mergetool (danlimerick.wordpress.com)

The download can be found here. Choose Browse by component->Clients->Visual Merge Tool as you do not want to download the whole Perforce client package. In the installer for P4Merge you can choose which components you wish to install, you only need the Visual Merge Tool (P4Merge).

Install p4merge and then set it as your merge tool for git by running the following two config commands:

git config --global merge.tool p4merge
git config --global mergetool.p4merge.cmd 'p4merge.exe \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"'

P4Merge can be used for doing diffs and merges. If using P4Merge for diffs then call:

git difftool

If the file you want to compare is already staged then use the –cached switch after that command.

When Git tells you that there has been conflict, to resolve it type:

git mergetool

This will open P4Merge and show three different versions of the file; your local version, the version you are trying to merge in (probably the master branch) and the base version. The base version is the common ancestor of the local version and the remote version. Choose which version wins or edit the merge manually and then save and quit P4Merge. Finally commit the merge and then remove any .orig files that may be left over. It should be possible to have git remove the .orig file automatically by setting mergetool.keepBackup to false in git config but I have not succeeded in getting that to work for me yet.

An example of using P4Merge

And this is what a 3-way merge looks like. The local version on the left, the base version in the middle and the remote version (the master branch) on the right. In the merge window at the bottom all three versions are currently selected. To select the local version, for example, I would click the blue diamond icon and then save and quit.

Related articles

• Git for Windows tip: setting an editor (danlimerick.wordpress.com)
• Git for Windows tip: Setting shell aliases with msysgit (danlimerick.wordpress.com)