VS2012 and VS2013 battle over .sln header

Question

I am developing on Visual Studio 2012 and another developer on 2013. As we share code on git, each Visual Studio version changes the .sln header to its liking. We get changes like this on practically every commit:

@@ -1,8 +1,6 @@
 <U+FEFF>
 Microsoft Visual Studio Solution File, Format Version 12.00
-# Visual Studio 2013
-VisualStudioVersion = 12.0.30110.0
-MinimumVisualStudioVersion = 10.0.40219.1
+# Visual Studio 2012

Is there a way to avoid this, other than manually reviewing changes to .sln and only committing them if they are relevant?

Note that adding the solution file to .gitignore is a bad idea, as valid changes aren't that uncommon.

Answer 1

I'm going to go ahead and answer just to summarize the bits of knowledge I have on this subject. To some extent, I think this an unresolved issue with git. The standard answer is "don't check binaries and metadata into a VCS", but sometimes the reality is that you need to share some amount of IDE/compilation configuration information, but you need to support multiple compilers/OSes/versions/etc.

Obviously, .gitignore is useful for anything that is truly user-dependent or compiler-generated. You can figure out the best items to ignore fairly easily on your own, or you can peruse the many lists available online for different compilers and IDEs.

However, some files are necessary but still dependent on factors that change from user to user or machine to machine. In my experience, the .vcxproj files of a Visual Studio C project have been offenders in this vein. The problem is that VS2010 and VS2012 want to use different versions of the PlatformToolset. The solution was to use conditional statements:

<PlatformToolset Condition="'$(VisualStudioVersion)' == '10.0'">v100</PlatformToolset>
<PlatformToolset Condition="'$(VisualStudioVersion)' == '11.0'">v110</PlatformToolset>

I don't think this idea will work in your specific case, but it probably will work in many. For your situation, I think you have to decide what the "canonical" version will be (i.e. pick a default compiler/IDE/version/machine/whatever), and then any situation that strays from that will need to avoid checking in conflicting sections. The easiest way to do that is to use git add -p, either on all of your changes or just for the files known to be problematic. Only add the parts that are useful for everyone, and for the rest, if they get in the way of a rebase or something, you can either git stash them or blast them with git checkout -- <filename> after you've committed the important parts.

This issue (or a very similar one, at least) has also been brought up here, but at the time of writing, the one answer is not very helpful. This may also have some relevant discussion, but again, true solutions that relate to your problem are somewhat lacking.