frequent git merge conflicts in lib.plist

[ArrowType]

Scenario: working on a UFO with one or more collaborators, via Git, and both parties have edited the glyph set of the same UFO.

It seems that a majority of the time, this results in several merge conflicts in the lib.plist when one of us subsequently tries to git pull the changes from the other.

Why all the conflicts?

I understand in a general way why this happens: we may have changed glyph sorting when editing the glyph set, and this moves around many lines of code in the lib.plist. Then, Git sees these all as lines changed, and many of these changed lines might have had the same line numbers as lines changed by the other person.

Sorting with the same script before merging does prevent many of the conflicts.

However, it seems that conflicts don't always happen, and sorting similarly doesn't always prevent conflicts. Sometimes, just adding glyphs in one branch, then merging those updates, results in conflicts. So, I'm unconfident that I have a full or proper understanding of just why there are so many merge conflicts in plists. If someone with more Git experience can give me more insight into this, I would be very grateful!

What happens if I just "accept both" for every conflict? Do resulting duplicate lines get auto-fixed by RoboFont?

The conflicts tend to be added lines from me, plus added lines from wherever I'm pulling changes from.

So, a dumb and fast way to deal with such merge conflicts is by just "accepting both" changes. Put another way, I just delete all the syntax put in by Git to show the conflict: <<<<<<< HEAD, =======, and >>>>>>> branch.

It seems that the conflicts are all added lines, and it seems that solving this in the dumb-and-fast way doesn't lead to any issues. So, I think RoboFont is accepting this, and just resolving any duplicate lines in lib.plist?

If this is the case, it would be handy to know, because I could pretty easily write a script to accept all changes, across selected lib.plist files with conflicts. Or, would this script be as potentially dangerous as it sounds?

Thanks for any details and insights!

[ArrowType]

Awesome, thanks for the suggestions, @gferreira!

Yes, we are using ufoNormalizer, and that probably is helping. :)

it could even be made automatic by hooking into a fontWillSave or fontDidSave observer

Oh, good idea! I suppose this would be very handy if set up as a startup script for collaborators, as well.

The biggest problems are solved by sorting before committing, so I'll try to hook up the sorting script like this, and report back if there's success.

[gferreira]

hello @ArrowType,

are you and your collaborators using ufoNormalizer before commiting? it not , please give it a try – it should help to reduce the noise between commits. you can turn it on/off in the Preferences Editor using the setting shouldNormalizeOnSave.

if ufoNormalizer is not enough, you can also try using a script to apply your own rules when saving or before commiting. it could even be made automatic by hooking into a fontWillSave or fontDidSave observer…

good luck & let us know how it goes!