Herding Code 132: Phil Haack, Keith Dahlby and Paul Betts on Git for Windows developers

In this episode, they guys talk with Phil Haack and Paul Betts (both new GitHubbers) and Keith Dahlby (author of posh-git, a set of PowerShell scripts which provide Git/PowerShell integration) about using Git on Windows.

Download / Listen:

Herding Code 132: Phil Haack, Keith Dahlby and Paul Betts on Git for Windows developers


Show Notes:

  • Paul begins with talking about why he thinks Git is cool, starting with the ability to create a clean source history that’s based on intent.
  • Phil says some people who aren’t used to distributed version control get the wrong impression of rewriting history. The idea is that you’re rewriting history as you work locally to build a clean commit. You don’t generally rewrite history once you’ve pushed to the master repository.
  • Keith says he tells people that when you push, it’s permanent. Until then, you can pretend you’re perfect. It’s just a save point – this reminds Jon of a quote from Dave Ward that this is like the ability to create save points anywhere in a video game.
  • Scott K says this is all great in theory, but he never sees people taking advantage of history rewriting. He goes on to say that he loves GitHub but hates Git because Git hates developers – rewriting history is way too hard.
  • Phil says that this makes more sense when you think of this in terms of replaying changes.
  • Phil says that he really started liking Git after reading the site Think Like (a) Git.
  • Paul says that he thinks this would be a lot easier to understand if you could see and work with things visually. Scott K says gitk kind of works but it’s clunky. Keith talks about gitk a bit more.
  • Scott K talks about how he regularly ends up with a corrupted state and asks for recommendations. Paul says the solution is to use either git reset or git rebase and explains what they mean. Jon asks for more info, and Paul talks about git reset –hard.
  • Phil talks about the importance of following an established workflow to avoid problems or getting in a state you don’t understand. He talks about the published workflow they use for the NuGet Gallery. Paul talks about how he and Phil are working on improving the interface to make it easy to follow working patterns.
  • K Scott talks about one confusion is that there are so many commands and parameters. Keith says that you can get by with a tiny subset, and can grow as needed.
  • Kevin asks if it’s possible to get your repository into a corrupted state, or if users are just getting confused by a valid state. Paul talks about some finer points of how things are stored and wraps up by saying really the only way to lose work with Git is to mess up or delete uncommitted changes or files.
  • Twitter question from @LeeFlannery: "can you discuss how command line git for Win isn’t so scary – stop waiting for integrated VS tooling to use git." Paul talks about how the MSysGit makes things unnecessarily confusing by making you think you need to use the Bash prompt.
  • Twitter question from @JavierLozano: "Why use powershell instead of bash for a console client? What are the gains?" Keith explains how posh-git gives you a Windows native experience (e.g. Windows style file paths). Phil talks about how the posh-git tab extensions give you an IntelliSense-ish experience with Git. Keith explains that posh-git does things like keeps track of which file have been added, so you can autocomplete files you’re adding rather than have to type them out.
  • Scott K says that posh-git was slow when he tried to use it and asks if performance has been improved. Keith says that posh-git calls git status on every action to offer contextual tab expansions and explains how to disable that for faster performance.
  • Keith talks about installing posh-git using psget, and more advanced use by cloning the posh-git repo and customizing it. Jon asks why installing posh-git in command-line didn’t work in the PowerShell ISE, and Keith explains that there are separate profiles for PowerShell command line, PowerShell ISE, and the NuGet Package Manager prompt in Visual Studio.
  • Question from John Sheehan: "What are some of the other things outside of tooling that are impediments to Windows users adopting Git." Paul lists several: line endings, SSH keys, the MSysGit install, and the git commit using vi in compatibility mode.
  • Keith says that MSysGit isn’t Git for Windows, it’s Git for Linux developers on Windows – it doesn’t behave like Windows at all. Keith asks who runs MSysGit.
  • Phil says there are a lot of conceptual obstacles to adoption, and says that he thinks it’s necessary to make it easier to do simple things without worrying about obscure and advanced options.
  • Jon talks about the frustrations in typing in the SSH passphrase and asks for suggestions. Paul talks about ssh-agent.
  • Jon asks for specifics about what Paul and Phil are working on. Paul say the idea is similar features to GitHub for Mac – not necessarily in design, but featureset.
  • Jon says that he likes how the TortoiseHg tooling shows the command-line version you could have typed when you perform operations in the GUI. Paul agrees that’s useful, and Keith points out that it’s available in Git Extensions.
  • Scott K says that he likes the built in Mercurial server and says it’d be nice if Git made it easier to run a Git repo on Windows. Paul says that it’s really easy to set that using a fileshare. Scott K says he uses that, but it’s not as discoverable as the Mercurial webserver. Keith talks about how setting up he’s seen this set up using per-user shares.
  • Twitter question from @jeremydmiller "Are you concerned that folks spend so much time debating and tweaking their Git workflow that they’ll forget to actually code?" Phil and Keith discuss two popular GitHub workflows: GitHub Flow and git-flow.
  • Twitter question from @kppullin "why must line endings be so painful!" Paul explains the source of the problem and how autocrlf tries to solve that, and there’s a general about how problems occur.
  • Keith talks about using gitattributes to do things like telling Git to use C# differencing with .cs files.
  • Jon asks finding good, non-hostile documentation. Scott K says that all the books focus on happy path documentation rather than useful stuff. Some useful online resources are listed, including Think Like (a) Git, The Git Parable, and ProGit.org.
  • Keith jokingly asks if we can talk about why Git is better than Mercurial. Jon takes the bait, and hilarity ensues.
  • There’s a long discussion about the usefulness of a clean history and the ability to accurately use "blame" to understand when a bug was introduced.
  • Things start to wrap up and K Scott asks for last thoughts. Paul mentions GitPad, which sets Notepad as your Git commit editor. Keith recommends Console2. Phil points out a neat hidden feature on GitHub – using T to get incremental search.

Show Links:

  • stevestreeting

    FYI a really easy way to collapse a bunch of local (unpushed) commits in Mercurial is ‘hg strip -k’. Combine that with ‘hg rebase’ of local branches you haven’t pushed yet, and ‘hg push -b’ and you can do most of the local history editing / per-branch pushing options you’re talking about as git advantages.

    Much of the problem is the Mercurial documentation leads you to think you need Mercurial Queues to perform this stuff. You really don’t – git is still more ‘natural’ about these things, but you can still do them.

  • Looking forward to the “git for windows” mentioned by Haack and Betts. I think git bash is not bad, I have no problem using it, but it would be great if there is a better alternative to gitk (git GUI).

    FYI there is a VS plugin for git on codeplex: http://gitscc.codeplex.com/

  • Rob Heckart

    In regards to “Keith talks about using gitattributes to do things like telling Git to use C# differencing with .cs files.” where do I find more info about this? My Google searches are returning nothing useful..

  • Margo

    For the windows-based developer, GitExtensions is really just a fantastic way to go. It’s “visual” yet stays close the core of Git, so you can come up to speed quickly. It works with Visual Studio, but frankly we don’t bother with that.

    http://nvie.com/archives/323 also helped provide nice info and visual guidance on branching.

    Between those two things, it works great. I dragged my feet on changing version control systems for a LONG time (as much as I hated VSS, it worked and was simple, unlike TFS). Now I think Git and source control is a great and useful thing!

  • JaredPar

    In the show it was mentioned that Visual Studio extensions are possibly responsible for incorrect / inconsistent line endings. In particular VsVim was mentioned as possible offender.

    This was definitely the case in VsVim up until version 1.1. New lines were incorrectly hard coded to CRLF even if the file was LF. Since version 1.1 it now uses the Visual Studio mechanism for line ending detection. If you see any more problems please do send me a bug report.

    Issue tracking bad line ending handling.



  • Jeff

    Great episode! I’m looking forward to the GitHub for Windows as well – though I’m perfectly happy with the combination Git Bash and SmartGit for visualizing the repository.

    It is mentioned a few times that the default installation of Git for Windows installs Vim in compatibility mode. I don’t know if this was once the case, but the latest version has vim set to nocompatible.

  • TomasJansson

    Great episode with a lot of useful tips.

    This is a small help for Jon Galloways frustration regarding typing in the passphrase on every commit. You don’t have to put in your passphrase everytime, there is a work around. Git has a configuration called askpass which allow you to execute a program when git asks for password. I hacked together a small program that allows you to store your password in the protected storage: https://github.com/mastoj/EasyPass, and then you can set this program to be executed through the askpass configuration.

    It is a hacky solution but it works.