How do you efficiently track changes in a .kml when modifying it with Google Earth?

Question

We use git to track changes made to a shared .kml file. We use this .kml file as a database of project sites that we can view in Google Earth. However, whenever a user saves modifications to the .kml made in Google Earth, GE also saves a ton of trivial changes to the stylistic data, e.g. the scale of the pins. The git diff then looks like the code below.

I thought that forcing users to update to the same version of Google Earth across machines might fix the problem, but it didn't.

How can we setup Google Earth to save only substantive changes?

Thanks!

            </Style>
-       <Style id="inline">
-               <LineStyle>
-                       <color>ff0000ff</color>
-                       <width>2</width>
-               </LineStyle>
-       </Style>
-       <Style id="s_ylw-pushpin_hl4">
+       <Style id="s_ylw-pushpin00">
                <IconStyle>
-                       <scale>1.3</scale>
+                       <scale>1.1</scale>
                        <Icon>
                                <href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href>
                        </Icon>
                        <hotSpot x="20" y="2" xunits="pixels" yunits="pixels"/>
                </IconStyle>
        </Style>
-       <Style id="s_ylw-pushpin010">
+       <Style id="sn_grn-diamond0">
                <IconStyle>
                        <scale>1.1</scale>
                        <Icon>
-                               <href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href>
+                               <href>http://maps.google.com/mapfiles/kml/paddle/grn-diamond.png</href>
                        </Icon>
-                       <hotSpot x="20" y="2" xunits="pixels" yunits="pixels"/>
+                       <hotSpot x="32" y="1" xunits="pixels" yunits="pixels"/>
                </IconStyle>
+               <ListStyle>
+                       <ItemIcon>
+                               <href>http://maps.google.com/mapfiles/kml/paddle/grn-diamond-lv.png</href>
+                       </ItemIcon>
+               </ListStyle>
        </Style>
-       <Style id="sh_ylw-circle0">
+       <Style id="sh_grn-diamond0">
                <IconStyle>
-                       <scale>2.36364</scale>
+                       <scale>1.3</scale>
                        <Icon>
-                               <href>http://maps.google.com/mapfiles/kml/paddle/ylw-circle.png</href>
+                               <href>http://maps.google.com/mapfiles/kml/paddle/grn-diamond.png</href>
                        </Icon>
                        <hotSpot x="32" y="1" xunits="pixels" yunits="pixels"/>
                </IconStyle>
                <ListStyle>
                        <ItemIcon>
:

Answer 1

Two things come to mind - one is to force the users to be careful what they commit before they commit it (interactive staging with git add -p) and the other one is to write your own custom smudge filter (using git attributes) so that you don't see any unnecessary changes in your diffs.

1. Interactive staging

Before you create a commit, instead of just adding the whole file, you can add it piece by piece. Only what you add will be commited by git in the end.

This can be achieved with git add -p. Once you do that, a prompt will show up and ask you for specific hunks of code if you want to add, split, quit, not to add, etc.

The downside of this is that there might be the case where you cannot split a big hunk and separate the important part of your file from the trivial part. For instance, the coordinates you want to stage and the styling you don't want to might be too close to each other and thus you will be forced to commit something you don't necessarily want.

In my opinion, this would be the easier option to implement and work with. However, if you do need these stylings (I'm using "need" here lightly as the smudge option might prove dangerous), then you can create a smudge/clean filter

2. Smudge filter

This would run each time you do a checkout and will apply the specified filter. The staging area will be clean, but the code you look at would be different since it would pass through the smudge filter. This smudge filter has to be specified in the .gitattributes file (docs). The filter itself can be a regex that matches any xml styling you don't like and just discard it (this is dangerous). Only consider this option if you are okay with loosing such parts of your data

The negative part of this, as already mentioned, is that you also have to create a clean filter that reverses what the smudge did (if necessary), which in your case would be quite difficult since that information would be difficult to match and re-create.

Apart from the documentation, VonC has a nice answer to how to create such a filter and you can also filter part of a file as shown here.