6

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.

StackExchange saddens dancek
  • 3,318
  • 1
  • 27
  • 37
  • 4
    I have the same problem with 2010 and 2012. Since I'm in the minority of 2012 users, I just never check in the dangerous changes. It only rarely comes up, though, and for a few things in the `.vcxproj` files (for example), we were able to use conditional code to get it to work smoothly in both IDEs. – pattivacek Mar 12 '14 at 13:44
  • We're in the starting phase of a project and it seems like every third commit includes real changes to project/solution files. I guess just not committing the solution becomes a real alternative later on. – StackExchange saddens dancek Mar 12 '14 at 13:56
  • 1
    `git add -p` comes in handy for situations like this, too. It's true, I don't mess with the solution/project files much, but when I do, I almost always resort to `git add -p` just to make sure I don't stomp on something important. – pattivacek Mar 12 '14 at 17:59

1 Answers1

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.

Community
  • 1
  • 1
pattivacek
  • 5,617
  • 5
  • 48
  • 62