What triggers this problem analyzer?

You can track history for fields, name fields, and record types of standard and custom objects. To do this, history tracking must also be enabled on the parent object.
(N.B. some standard objects have history tracking enabled as default.)

We'll look to see if the field, name field, or record type has history tracking enabled, and check if the parent object is in the target. If it is, we'll check if it has history tracking enabled, too.

What problem is it solving?

If the parent object is in the target, and it has history tracking turned on, then there's no problem!

If the parent object hasn't been deployed to the target yet, then, once again, there's no problem!

However, if the parent object is already in the target, but history tracking is not turned on, then there is a problem! 

If you try to deploy a field, name field, or record type that has history tracking enabled before the parent object in the target org has history tracking enabled, the deployment will actually succeed. The target will pick up the change (you'll see an enabled checkbox in your field-specific tracking, though the parent still has it unchecked).

The problem is that this change is invisible when retrieving through the metadata API, so re-running the comparison after the deployment will still show that the field tracking history of the target is set to false. Another issue is that even though the field history tracking is now set to enabled, you still can't actually track the field's history unless the parent has it enabled.

How does it work?

Rather than remove the history tracking field from the xml of the sub-component, we'll add the history tracking field to the parent object.

Did this answer your question?