We are building our branch portal software discoverize on top of the mature Orchard CMS and incorporate important changes from the Orchard sources into our own software. Today, I wanted to add the CacheManagerExtensions class to discoverize to take advantage of some optimizations to the cache population strategy. The first commit contained changes to no less than 27 files. Manual work: go away! So I thought to myself: I'll just get the patch for this commit and apply it to my working directory :-) Well, guess what? There's no magic patch button on the commit page anywhere. Google and this blog post to the rescue… Download a Commit as a Patch It turns out to be as easy as adding .patch to the end of the commit url – and you get a beatiful text screen that you can save to a .patch file. Applying as much of a patch as possible Use git apply --reject abc.patch to apply all of the patch that can be applied to your current working directory – for the rest of the differences in the commit, reject files (.rej) will be created to not loose track of them. And that's all. Happy patching!

Git aliases are a great way to save you some valuable keystrokes but also to stop remembering verbose syntax to do simple things. One of these things I regularly do is fast-forwarding a local branch to the last commit of its remote tracking branch. There are – of course – several viable solutions to the problem but I like this one the most: $> git fetch origin master:master Yesterday, I've had enough of typing those same characters into my git console, so I finally set up the alias that I should have set up 3 years ago: $> git config --global alias.ff '!git fetch origin $1:$1' The first part of the command up to the apostrophe is simply how you define a git alias. The second part, wrapped in apostrophes, is the command that I want executed. Since I want to pass the branch name as an argument, I need to begin the command with an exclamation mark ! and write a full command line. Now I can simply call: $> git ff master I chose ff as the alias because I use it for fast-forwarding some branch that I'm not currently on. Happy git'ting!

Lately, I've been having a hard time with my Visual Studio installation because one day it just out of nowhere started crashing during startup. Starting VS with the /SafeMode flag avoided the crash but wasn't of much help to do major work since all my R# syntax highlighting and refactoring tools are not available in safe mode. First Try: Reset All Your Settings The first time I encountered the problem I found this answer on stackoverflow.com  helpful which suggests to: Reset all your Visual Studio settings by calling devenv /resetsettings from a command line prompt or after hitting the Windows key. Delete the folders %LocalAppData%\Microsoft\VisualStudio and %LocalAppData%\Microsoft\VSCommon Second Try: Uninstall GitExtensions Today, VS started crashing again and I was just happy with resetting all of my fine-tuned settings AGAIN. Luckily, a google search brought up this thread on the NCrunch forum and since I use NCrunch for test execution I went to have a look Here's what Simon had to say there: I'm thinking the problem was a GIT plugin installed by GitExtensions - I've read other reports about it causing problems, so I've removed it and things seem stable so far. To verify whether this was true in my case I just went ahead and uninstalled GitExtensions via the Control Panel – and Visual Studio would happily start again! What a relief. But I Still Want To Use GitExtensions… After uninstalling, go get the installer again (did you know there's a standalone version without msysgit and kdiff?) and during install unselect all the Visual Studio plugins like this: UPDATE: Keep Even GitExtensions' VS Plugin! A commenter to my answer to the VS crash problem on stackoverflow suggested that unchecking the option "Show current branch in Visual Studio" in GitExtensions under Tools –> Settings –> Appearance fixed the VS crashes for him: I used this hint to reactivate the GitExtensions VS plugin on my machine as well, because I use some of its features quite often. Now, you should be good to go! I'll try to get back to work now while my VS is running… Happy coding!

Not much else to say than what's mentioned in the title. I come across the need to do so mostly before deployments from my machine where I want to update my local master branch to the HEAD of the remote master branch. Here's how to do that: 1: git fetch origin master:master Thank you stackoverflow and Cupcake!

The scenario I'm facing quite regularly during development is that I want to change to a different feature branch that really someone else is working on to do some maintenance or the like. I know that I can just fast-forward my local branch to the current HEAD of the corresponding remote branch, but using e.g. a GUI such as the wonderful GitExtensions, I have to first check out my local branch and then merge the origin's head into it. This might not only take longer than needed but sometimes lead to problems when the solution is currently open in Visual Studio (depending on the differences between the two branches I'm switching between). Of course, I wasn't the first to want to get around unnecessary overhead, and this stackoverflow answer helped me find a solution to my "problem". For a branch named "design" simply do the following on a command line inside your repository: git branch -f design-2 origin/design-2 Git will answer with something like this: Branch design-2 set up to track remote branch design-2 from origin. And that's that. Beware: as stated in a comment of the above mentioned answer, … Just be very careful not to do that unless you've made absolutely sure the merge would be a fast-forward! Happy gitting!