Per-property conflict resolution

[jacobmarble]

Just getting started with vdirsyncer, starting with contacts. One of my first tests is a vcard like this:

BEGIN:VCARD
VERSION:3.0
UID:xu8wbtiol6loyvnm9hwpk697
fn:Sarah Miller
n:Miller;Sarah;
email;type=home;type=pref:sarahmiller@foo.com
REV:20161115T061350Z
END:VCARD

Change on side A (modify name):

fn:Sarah Millers
n:Millers;Sarah;

Change on side B (add org):

fn:Sarah Miller
n:Miller;Sarah;
org:foo;

As expected, this error is returned:

error: my_contacts/Default: One item changed on both sides. Resolve this conflict manually, or by setting the `conflict_resolution` parameter in your config file.

However, the changes themselves do not conflict. What I would like is to see both sides change to:

BEGIN:VCARD
VERSION:3.0
UID:xu8wbtiol6loyvnm9hwpk697
fn:Sarah Millers
n:Millers;Sarah;
org:foo;
email;type=home;type=pref:sarahmiller@foo.com
REV:20161115T061350Z
END:VCARD

Is it worth my time to implement a diff checking whether changes can be resolved without forcing one side to simply override the other? Looks like this could be implemented with ["command", "my_command"].

• I'm being pedantic; just use "A wins".
• Implementing in Python would be a helpful PR.
• This could be useful; implement as an external command and share elsewhere.

[untitaker]

I'm in the middle of refactoring the related code (vdirsyncer already ignores changes that just reorder properties, e.g.), ignoring case of property names is totally a good idea that can be done by default.

[untitaker]

Ah, you want the normalized variant in the diff as well! This can actually be solved as part of https://github.com/pimutils/vdirsyncer/issues/375

[jacobmarble]

I edited my original comment.

This feature request is about merging a vcard that changed on both sides, but in non-conflicting ways. In my example, side A changed the name, while side B added an org. Some normalization would certainly be required to implement.

[untitaker]

I see. That merging strategy, however, requires that vdirsyncer stores the entire item content inside the status (to figure out which properties changed) instead of just a hash. And it is blocked by #375 as well.