Git merge between branches keeps deleting a bunch of kerning and groups

I’m attempting to use Glyphs for a project in which I have a collaborator who is working on Cyrillics. I use Git to version my work, and to merge collaborative work. We were working purely in UFOs for most of the project, and that has its difficulties, but things tend to merge without too many headaches. However, we have recently migrated this into a Glyphs project, because we want to use a couple of key plugins (Mini Proofer and KernOn).

There are many things I love about Glyphs! I am constantly recommending it to people who ask me what font editor they should use.

However… I’m still trying to get used to using it effectively with Git.

The biggest problem I’m currently facing: if I work on some drawing, spacing, and kerning (using KernOn) in my main branch, then do a Git Pull Request to merge that work into the cyrillic branch, a bunch of kerning data & groups are mysteriously lost. Basic things like ATA AVA lose kerning and groups.

Of course, this might be related to the use of KernOn, but I don’t think that entirely explains it. After all, KernOn is partly just making groups and adding kerns. It also adds a few things into UserData, but I don’t think it should be enough to break merges like this…

Ultimately, I can rescue kerning by using MergeGlyphs, but is there a more direct solution, or does the Glyphs format just not work well in Git? I know there are tons of projects that use both, so my hope is that I’m just missing some technique that will make it work better.

FWIW, my collaborator and I are both on version 3.1 (3133), and using the file format version 2. (Would file version 3 do any better in Git?)

I’ve already set a couple of Custom Parameters to avoid at least some diffing noise:

I’m happy to email a before/after version of the Glyphs source, if that would be helpful for diagnosing things.

Thanks so much for any insight!

Version three offers two file format flavors, a single file (.glyphs) and a package file (.glyphspackage). The latter is much better suited for version control since every glyph is stored in a separate file. Maybe then you also don’t need two separate branches?

You can find out more in the Handbook, section 15.2 Source Formats on page 223 and more specifically in subsection 15.2.2, Glyphs File Package on the next page.

Regarding the lost data due to Git merges, could you send us the three files (the one from the main, the one from the cyrillic branch, and the merge file, just in case your merge is behaving differently for some reason)? Either via private message here on the Forum or via email to support at this domain and we will have a look at what goes wrong, and if we can make it so this does not happen.

I never use merge. I lost some stuff this way. For long running branches, it is much saver to cherry-pick. At least t works quite well for me.

So cool that the forum has private messaging now! I’ll send an email, though, because each file exceeds the 4MG message limit.

Thanks for the .glyphspackage tip – that sounds potentially super helpful! I would be very hesitant to have two people working in the same branch, though, just because it would open up more potential ways to get confused.

And hmm, I handed considered that cherry-pick might be a better option, here. I’ll read up on that as well!

Okay, I’ve sent the email. I’m just updating this thread with most of the email contents, in case someone else comes along and has a similar issue.

The file names I sent indicate what they are:

  • A “Main Branch” file, which has kerning
  • A “Cyrillic Branch” file, which has kerning
  • A “Merge Kerning Lost” file, which is a merge of the two, but with a lot of lost kerning info.

Sorry for the delay in sending that email… for a while there, I started suspecting that a crash or interruption to KernOn processing might be the cause of lost kerning data. Indeed, some kerning does get lost if I interrupt KernOn while it’s generating new kerning.

But, I then re-tested a merge between new kerning in the main branch, and kerning in the Cyrillic branch, and… indeed, kerning was lost again.

It seems that this happened in several contexts: one was a Pull Request on GitHub, where a merge seemed to erase kerning data. The more recent merge was done with VS Code, just accepting the default merge resolution, and again, kerning was lost.

I’ll test out the .glyphspackage format a bit, but my first impressions are that git diffs are MUCH more sane! I can actually see what has changed between saves. I love it! I’ll try it with a few merge tests, and see how that goes.

Okay, after a quick local test of .glyphspackage – making a new branch and running a kerning update there, then merging that back into main – this approach seems much better!

I’ll know with more certainty once my collaborator is able to pull the updates and check on their end, but I think that format change might solve the majority of my problems here. :crossed_fingers: I’ll post an update if not!

Thanks for your help here!

1 Like

Just out of interest, how are you collaborating on kerning? How do you facilitate the merge? Do have one file with only Cyrillic, one file with only Latin, run Kern On on both separately and then merge the files?

Technically, it is possible to simply merge the two files and then run Kern On. You would need to merge the user data per master manually beforehand (as Kern On model names are stored in the masters’ user data, which then reference a kerning pair), but there is a built-in feature in Kern On to import models from another font. Don’t know whether a git merge would work here too, maybe it would.

This would mean you could simply run Kern On once on the merged file.