This will ‘auto-resolve’ the version conflicts (which are going to be three way by definition). One final thing to consider – should this filter fix up deltas as it goes, so for example the deltaV2 on the parent dependency element, or should it just do a simple local change and we then have a final process which checks for any unresolved conflicts and when none are found removes all deltaxml attributes including deltas, version-order and content-type?
Putting this all together
The existing git merge driver: deltaxml/git-merge-driver will need an input filter for orderless and keying and also the above output filter and possibly as discussed above a filter to tidy up delta attributes.
This necessitates changing the driver code and the API changes needed require the move from the
ThreeWayMerge class to the
There are certainly possibilities to extend this further; dependencies in POMs was the first example that comes to mind, it wasn’t an exhaustive analysis of the POM syntax.
This post has concentrated on an example and use-case for automatic conflict resolution, a future post will look at interactive conflict resolution.