Really the notion of versions for a bunch of scripts on which noone depends seems a bit silly…if a feature seems to be missing, get latest from master. If it’s still missing, send me a pull request (or log an issue). But I suppose it’s good to check in periodically to document what we’ve been up to.

New in this release:

• Git 1.7.2 or better is required
  • And I fixed a bug that prevented it from working with 1.7.10.
• Prompt status now plays nicely with posh-hg without extra hacks
• Functions are now provided for using ssh-agent to save credentials
  • If you get a warning that ssh-agent could not be found, either add an ssh-agent PowerShell alias or add the path to Git\bin in your PATH environment variable
• Branch in prompt status is now colored according to being ahead of or behind a tracked reference (see readme for an explanation of default colors)
• Added tab expansion for a bunch of new commands and options (remote refs, revert, tfs, bisect, submodule, and more!)
• Tab expansion works for aliases of git (I recommend g)
  Contributed by Mark Borcherding
• The list of commands expanded by default now covers most porcelain commands.
  • You can always get all commands to expand by setting $GitTabSettings.AllCommands = $true
• Values of $LASTERRORCODE for the last real command are preserved through the prompt
• If prompt performance for a repository is not acceptable, that repo’s path can be added to $GitPromptSettings.RepositoriesInWhichToDisableFileStatus
  Contributed by Eric Lee
• posh-git should work in the Nuget Package Manager Console, though you’ll probably want to change the colors
• The GIT_DIR environment variable is used if defined
  Contributed by Daniel Dabrowski

Several others have contributed bug fixes as well—thanks everyone! It’s pretty awesome to work on something that someone else cares enough about to help improve.

If all goes according to plan, the next time you hear from me (about posh-git) will be to announce that migration to LibGit2Sharp is complete. I’m optimistic that the move will address the persistent performance concerns for large repositories. If you have a particularly troublesome repo, feel free to try my libgit2 branch and let me know if it’s better (or worse).

Speaking of posh-git, there are a bunch of new goodies in my master branch including tab expansion for remote branches, support for the Nuget console, and easier integration with posh-hg. I’ll post more details with the upcoming v0.4 release.

• Actor Model Programming in C# by Chris Patterson
• Crafting Wicked Domain Models by Jimmy Bogard
• Dynamic .NET Demystified by me

I had a great time at CodeMash last year, and this year is shaping up to be even better. Registration opens today (Oct. 24) at 10:24 AM EDT and you’ll want to reserve your spot soon—last year’s event sold out in less than four days!

If you do make it to the event, please ping me on Twitter so we can meet up!

1. Local Branching

More than anything, cheap local branches have changed how I work. I don’t know any developers that have the luxury of only working on one thing at a time. Not only do local branches provide the perfect mechanism to compartmentalize work on different features (or just ideas you’d like to try), but Git’s branching mechanism also works great for trying different approaches to the same problem. It’s trivial to reset a branch back a few commits if an idea doesn’t work out, or create a new branch from a few commits ago to see if there’s a better way.

The other advantage of local branches is that they’re not public unless you want them to be. Not only are centralized branches slower to work with and commit to, the ceremony required to set them (if you have permission at all) attaches a feeling of permanence—I’m less likely to commit something that’s not necessarily finished, but may still be useful. I don’t have these reservations with Git—my main repository at work has maybe 20 branches of refactorings, spikes and other works in progress that I’m free to revisit as time allows without feeling self-conscious about their current lack of polish.

2. Smarter Merging

Because of Git’s focus on file content rather than file location, it’s much better at resolving merge conflicts for you, especially across renames. That’s not to say you’ll never get conflicts, but they’re typically real conflicts—files deleted in one branch and modified in another, overlapping Visual Studio project file changes, etc. And for those you can hook up a 3-way merge tool like Beyond Compare or P4Merge to make quick work of them.

3. Pause and Resume

So your boss comes in and says something to the effect of “stop everything you’re doing and make this change for the CEO.” What do you do? In SVN you might create a patch file of your work in progress and revert. In TFS you might shelve your changes up to the server. In Git you have a two options that are built right in:

1. git stash, which pushes the changes in your index and working directory onto a local stack of stashes from which you can pop at any time. Your typical workflow would look something like this:

   $ git stash save "I love interruptions!"
   $ git checkout master -b pti
   # ... save the day ...
   $ git checkout my-feature
   $ git stash pop

   The disadvantage of stashes is that they’re not explicitly tied to the branch where the work happened. The longer it takes to get back to what you were working on, the higher the chance you’ll forget you had some work stashed.

2. Stage all your changes and make a temporary commit that you’ll later revert:

   $ git add -A && git commit -m "I love interruptions!"
   $ git checkout master -b pti
   # ... save the day ...
   $ git checkout my-feature
   $ git reset HEAD~

   The kicker is the final command, which moves the my-feature branch pointer back one (to HEAD‘s parent) but leaves the working directory unchanged—keeping your old work in progress. The advantage of this approach is that the temporary commit lives with the branch where the changes belong.

It doesn’t take long for both of these operations to become second-nature, greatly decreasing the impact of these interruptions.

4. Rewriting History

Pretending a temporary commit never happened is just one example of rewriting history, which becomes a fundamental operation for an intermediate/advanced Git user. But first, our cardinal rule:

Once a commit is pushed, it’s permanent.

History that has been shared with others is off-limits for rewriting unless you have explicitly communicated that history may be rewritten. For example, I routinely overwrite branches I push based on pull request feedback, but once something hits posh-git‘s master branch it’s there for good.

So with that out of the way, I present my corollary to the cardinal rule:

Until you push, pretend you’re perfect.

In the simplest case, this might simply mean using git commit --amend to fix a typo in the last commit’s message, or include changes to a file that you forgot to save. For more complex needs, like pretending you wrote your tests before the implementation, check out the amazing interactive rebase.

5. The Staging Area

Some people view Git’s staging area as an annoyance—an extra step between code and commit. I simply see it as your standard commit dialog with all the boxes unchecked by default. Checking all the boxes is as simple as git add -A, which I alias as git aa (git config --global alias.aa "add -A"). Or you can use git commit -a to stage all changes before commiting (though this won’t pick up additions or deletions).

The real power, though, comes from the ability to stage (git add --patch) and unstage (git reset --patch) parts of your changes before commiting. You can even use git checkout --patch to revert some changes in your working directory without affecting others, or even to pull in partial changes from another commit altogether.

I use this feature on an almost daily basis to separate cosmetic changes from refactoring from new feature work, without having to undo some changes so that I can commit the others. The result is more smaller, atomic commits that separate inert changes from those that actually change behavior.

Tip of the Iceberg

Ultimately these are just a few of the things that have convinced me Git is worth the learning curve, worth the cost to migrate, worth the cost to retrain your staff; and this doesn’t even touch on the advantages and flexibility of Git’s distributed nature. I just hope to pique your interest enough that you give it a try for yourself.

And if you’re already using Git, how does this compare with your list of must-have features?

1. Don’t run your build server as a Windows Service. I don’t like this option as it’s harder to maintain.
2. Run the build service as Local System with “Allow service to interact with desktop”. This limits your ability to manipulate the context in which builds run, for example it’s quite tricky (I believe it’s possible with PsExec) to configure Internet Explorer settings (turn off Auto-Complete, etc) for LocalSystem.
   

A third option now is to run the build service as a user of your choice and set “Allow service to interact with desktop” through the Windows Registry. A Code Project article identified the necessary Registry setting, but still suggested the account must be LocalSystem. However, the same setting appears to work for other accounts as well. I’ve put together a simple PowerShell script to make the change; just run it with administrative privileges:

$svcName = Get-Service -DisplayName *cruise* | select -Exp Name
$svcKey = Get-Item HKLM:\SYSTEM\CurrentControlSet\Services\$svcName

# Set 9th bit, from http://www.codeproject.com/KB/install/cswindowsservicedesktop.aspx
$newType = $svcKey.GetValue('Type') -bor 0x100
Set-ItemProperty $svcKey.PSPath -Name Type -Value $newType

If you’re not a PowerShell person:

1. $svcName = Get-Service -DisplayName *cruise* | select -Exp Name
   Find the name of the Cruise Control service (CCService).
2. $svcKey = Get-Item HKLM:\SYSTEM\CurrentControlSet\Services\$svcName
   Grab the Registry key for the service.
3. $newType = $svcKey.GetValue('Type') -bor 0x100
   Get the Type value with the 9th bit set.
4. Set-ItemProperty $svcKey.PSPath -Name Type -Value $newType
   Set the Type value. The PowerShell Registry provider isn’t particularly intuitive here, IMO.

Installer

Previously the setup process for posh-git was undefined. Daniel Hoelbling was kind enough to put together a getting-started post, but I decided to make it even easier. Assuming Git and PowerShell are configured correctly (see readme for details), getting started is trivial:

cd C:\Wherever
git clone https://github.com/dahlbyk/posh-git.git
.\posh-git\install.ps1

At this point the sample posh-git profile will be loaded as part of your PowerShell profile. If you don’t like the sample profile, feel free to grab the pieces you want and discard the rest (so you can use posh-hg too, perhaps).

If you already have posh-git installed, just cd into your posh-git directory and pull from my master branch:

# If you don't already have me as a remote...
git remote add dahlbyk
git pull --rebase dahlbyk master

You don’t need to run install.ps1 again; just open a new PowerShell session and you’re good to go.

Performance

By taking a dependency on msysgit 1.7.1, all status information is now retrieved in a single call (git status -s -b). This still means git status is called for every prompt, so if status is slow for your repository your prompt will be slow too.

If it’s still too slow for your taste, you also have the option to set $GitPromptSettings.EnableFileStatus = $false. This will preserve branch information for the prompt, but skip everything else (counts and tab completion for added/modified/deleted files).

Finally, you can set $GitPromptSettings.Debug = $true to see how long the various steps take behind the scenes. If your environment is anything like mine, the majority of the time will be spent in git calls.

Tab Expansion Updates

• Fix for git rm during deleted/updated merge conflict
• Branch expansion for cherry-pick, diff, difftool, log and show
• Normal expansion through simple aliases (e.g. alias.dt = difftool supports git dt <tab>)

Next Steps

• I’d still like to get some testing in place so I don’t break things unintentionally
• I’m considering moving away from regex to parse commands for tab expansion — anyone feel like writing a git command parser in PowerShell?
• I’d like it to be easier to use posh-git and posh-hg together, so I may revisit how they hook into tab expansion

As always, your feedback is appreciated. If you’d like posh-git updates between release posts, you can also follow me on Twitter.

1. Checkout Windows-style, commit Unix-style (core.autocrlf = true)
2. Checkout as-is, commit Unix-style (core.autocrlf = input)
3. Checkout as-is, commit as-is (core.autocrlf = false)

The first option is the default, which I find rather unfortunate—I don’t consider line ending manipulation to be the responsibility of my VCS. Instead, I prefer to keep core.autocrlf set to false and let my text editors deal with line endings. (If you like having core.autocrlf set to true or input, I’d love to hear why.)

One downside of turning off autocrlf is that the output of git diff highlights CR characters (indicated by ^M) as whitespace errors. To turn off this “error”, you can use the core.whitespace setting:

git config --global core.whitespace cr-at-eol

If your core.whitespace is already set, you should add cr-at-eol to the end of the comma-delimited list instead.

<h2>@("FS" + "Razor")</h2><p>@(    let even_odd s =        match s % 2 with        | 0 -> sprintf "%i is even!" s        | _ -> sprintf "%i is odd!" s    DateTime.Now.Second |> even_odd    )</p>

A useless example, but it works…as long as there aren’t unmatched parentheses (within a string or comment). So far the parser is a simple port of the C# parser, and as such is very procedural—it’s unclear if the underlying parser model will afford much wiggle room to take advantage of F#.

It’s been an interesting learning experience, as my first attempt to do “normal .NET” inheritance-based development in F#. Some random thoughts based on work so far…

• I still struggle to remember F#’s syntax for familiar class constructs (ctor, method, property, etc)
• I’ve been disappointed so far by my attempts to F#-ize the C# port
• I finally bothered to look up how to add assembly information in F#
  
• I learned about a few new ASP.NET 4 features, in particular PreApplicationStartMethodAttribute which uses a magic string (read: undiscoverable) to identify a method which can register the .fshtml build provider

There’s still a bunch of work yet to do, and I’d love some help if anyone is actually interested in using this in production…

• Tests for the parser and code generator
• Handling implicit transitions (@ without explicit block)
• Handling strings/comments
• Handling statement blocks
• Figuring out where F# needs special treatment in Razor (extra features or syntax that won’t work)
• MVC support? (@model)
• WebPages support? (branch doesn’t work yet)

In August 2008, Red Gate took over stewardship of .NET Reflector, one of the most popular .NET developer tools around. At the time, we said we would “continue to offer the tool for free to the community,” and we’ve made good on that promise. Since then, we’ve invested heavily in .NET Reflector:

• A Visual Studio plug-in, allowing you to jump direcetly to classes and methods in Reflector
• Support for .NET 4 assemblies
• Support for C# 4 and Visual Basic 10 language features
• Support for opening assemblies from the Global Assembly Cache
• Numerous bug fixes

Unfortunately, these investments have come at a higher cost than anticipated. As of version 7, due for release in March 2011, we will charge $35 for .NET Reflector. Version 6.7 will continue to be available for free—forever, but we hope you’ll find the new features of version 7 to be worth the investment.

We appreciate your continued trust in Red Gate to provide the best in tools for .NET developers.

The Setup

I started with an empty MVC 3 project and the Razor view engine.
We’ll let a view model figure out what’s going on with our controller’s Session:

public class SessionModel{    public SessionModel(Controller controller, bool delaySession = false)    {        SessionID = delaySession ? "delayed" : GetSessionId(controller.Session);        Controller = controller.GetType().Name;    }

    public string SessionID { get; private set; }    public string Controller { get; private set; }

    private static string GetSessionId(HttpSessionStateBase session)    {        try        {            return session == null ? "null" : session.SessionID;        }        catch (Exception ex)        {            return "Error: " + ex.Message;        }    }}

The model is rendered by two shared views. Index.cshtml gives us some simple navigation and renders actions from our various test controllers:

@model SessionStateTest.Models.SessionModel@{    View.Title = Model.Controller;    Layout = "~/Views/Shared/_Layout.cshtml";}<h2>Host: @Model.Controller (@Model.SessionID)</h2><ul>    <li>@Html.ActionLink("No Attribute", "Index", "Home")</li>    <li>@Html.ActionLink("Exception", "Index", "Exception")</li>    <li>@Html.ActionLink("Default", "Index", "DefaultSession")</li>    <li>@Html.ActionLink("Disabled", "Index", "DisabledSession")</li>    <li>@Html.ActionLink("ReadOnly", "Index", "ReadOnlySession")</li>    <li>@Html.ActionLink("Required", "Index", "RequiredSession")</li></ul>@{    Html.RenderAction("Partial", "Home");    Html.RenderAction("Partial", "Exception");    Html.RenderAction("Partial", "DefaultSession");    Html.RenderAction("Partial", "DisabledSession");    Html.RenderAction("Partial", "ReadOnlySession");    Html.RenderAction("Partial", "RequiredSession");}

Partial.cshtml just dumps the model:

@model SessionStateTest.Models.SessionModel<div>Partial: @Model.Controller (@Model.SessionID)</div>

Finally, we need a few test controllers which will all inherit from a simple HomeController:

public class HomeController : Controller{    public virtual ActionResult Index()    {        return View(new SessionModel(this));    }

    public ActionResult Partial()    {        return View(new SessionModel(this));    }}

[ControllerSessionState(SessionStateBehavior.Default)]public class DefaultSessionController : HomeController { }

[ControllerSessionState(SessionStateBehavior.Disabled)]public class DisabledSessionController : HomeController { }

[ControllerSessionState(SessionStateBehavior.ReadOnly)]public class ReadOnlySessionController : HomeController { }

[ControllerSessionState(SessionStateBehavior.Required)]public class RequiredSessionController : HomeController { }

And finally, a controller that uses the SessionModel constructor’s optional delaySession parameter. This parameter allows us to test RenderAction‘s Session behavior if the host controller doesn’t use Session:

public class ExceptionController : HomeController{    public override ActionResult Index()    {        return View(new SessionModel(this, true));    }}

The Reveal

So what do we find? Well the short answer is that the host controller’s SessionStateBehavior takes precedence. In the case of Home, Default, ReadOnly, and Required, we have access to Session information in all rendered actions:

If the host controller is marked with SessionStateBehavior.Disabled, all the rendered actions see Session as null:

I see this is the key finding to remember: an action that depends on Session, even if its controller is marked with SessionStateBehavior.Required,
will be in for a nasty NullRef surprise if it’s rendered by controller
without. It would be nice if the framework either gave some sort of
warning about this, or if they used a Null Object pattern instead of
just letting Session return null.

Finally, things get really weird if a Session-dependent action is rendered from a host controller that doesn’t reference Session, even if SessionState is enabled:

It’s pretty clear the issue has something to do with where RenderAction() happens in the request lifecycle, but it’s unclear how to resolve it short of accessing Session in the host controller.

So there we have it…a comprehensive testing of sessionless controllers and RenderAction
for the ASP.NET MVC 3 Release Candidate. Hopefully the inconsistencies
of the latter two cases will be resolved or at least documented before
RTM.