Diffing Files to Avoid Easy Goofs

A good habit learned at my last job has saved me a lot of embarrassment and bugs (same thing): Before committing a set of changes to source control, I look at the diff of each file. Look at the changes, read ‘em over, look for misspellings and placeholder notes-to-self and files I hadn’t intended to change; then make fixes and revert as needed. It’s like proofreading. Polishing the fingerprints off a product before sending it into the world. Checking your knot.

Shortcuts for diffing files:

  • In TFS, Shift–double-click a file name in the Pending Changes window. (You can configure TFS’s diff tool.)
  • In TortoiseSvn, double-click a file name in the “Changes made” panel of the Commit window.
  • In git and Hg… help me out here. I’m too used to a visual side-by-side. Recommend a nice explanation of getting the most from those in-line diff reports?

If that seems daunting because there are so many files to review, check in more often. I appreciate the mentors who have drilled into me: small, focused, atomic changes. It keeps me focused on what I’m doing. Make this one change, and every other stray thought that leaps to mind (“Ooh, I need to do this, too!”) gets tossed in a running text file, to be addressed later. How small is small enough? When it no longer feels onerous to diff all your files before checking in. ;-) In addition to keeping my thought process on-track, this habit makes it easy to review, fix, unwind, and selectively pick certain changes when I need to.

Small check-ins are like the extract-method refactoring. In code, when you have a collection of statements that do something, you’d extract them into a method so that you can name the something. Similarly, a focused check-in can have a descriptive and useful check-in comment.

The three habits fit together: small check-ins targeting a focused goal, with a useful commit message, reviewing the changes before checking them in. Reduces the number of times I have to think “Who the heck did—?! Oh, me. Heh.”

Related Articles:

About Sharon Cichelli

I am a Headspring Senior Consultant, developing custom enterprise software for our clients and leading training classes on the latest Microsoft technologies. I blog about .NET development, best practices in agile software development, and my nerdy hobbies.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://solutionizing.net/ Keith Dahlby

    In git you can configure a difftool (I use Beyond Compare) to do a visual diff. Usage is identical to diff. Note that this works best after you have committed, though to see changes in the index you can use “git difftool –staged”.

  • Guest

     I use ‘git add -p’ to review and stage my changes incrementally.

  • Anonymous

     Beyond Compare is nice.  You can also configure git and hg to use TortoiseMerge if you’re already familiar with the tool.

  • http://twitter.com/thomaslangston thomaslangston

    You get an inline diff tool on the commit window of TortoiseHg.  This takes a bit of time to become accustomed to, but I use it for almost all commit proofreading today. I use Beyond Compare when I need to a side by side diff, particularly if I’m comparing entire directories. 

    TortoiseHg commit window screenshot
     http://tortoisehg.bitbucket.org/img/vt_commit.png

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #854

  • Nadav

    If only VS2010 would use a consistant ordering in it’s generated code files…
    It’s very irritating to make a small change to a form (i.e. change the size of a label) and then when you view the diff you see 100 differences because VS2010 reordered the generated file :(

  • Guest

     Also if you’re using TFS, download the power tools and try the command ‘tfpt review’.

  • Anonymous

    Lots of great suggestions, covering git, Hg, and TFS. Thanks so much. 

    I’ve also found the “review before commit” workflow I was looking for with gitk (which was already installed, probably as part of installing git). It even supports “review before staging.” “gitk &” starts it in a separate thread, so that I can keep it open (refresh it with Ctrl-F5) and continue working. “gitk –all &” to view all branches.