Sorry to be beside the topic here, but I can’t help it:
Why do you have files with date and description? Use git and work with one single file, but a version history.
There is also the absolute killer Light Table — Formkunft
This looks amazing! (why am I only hearing about this now?!) will read up on it and try it. Thanks for sharing.
I do wish there was a tutorial on best practices on using git for a single file workflow;-)
However, there are times when it is necessary to have multiple files open and it would be useful to quickly be able to see the full name.
It’s very easy, honestly. Set up a GitHub repository, clone it onto your your computer, put a .glyphspackage file there (Save As > Format: Glyphs File Package) and make a commit every time you change things. Done.
1 Like
Chiming in here about the git, in order to tell you that you don’t even need a repository on GitHub. It can be just a folder in your Mac, that you turn into a git repository.
GitHub is just a way to also store a copy of your repo in the cloud. Which is useful for collaboration. Can be useful but is not required for git and version control.
Since when is this out and why didn’t I know about this until now‽ 
1 Like
I’m glad you said this Mark as I had the exact same thought when I seen Sebastians reply! How did I miss this?
1 Like
It’s not officially out just yet. Light Table requires Glyphs 3.2 (currently cutting-edge) and there are a few things unfinished that I want to get done before I can blindly hand the plugin off to users. (The diff view for staged, non-Glyphs files is still missing, which is unacceptable for a more public release.)
Until then, feel free to try it, and please report anything that does not work for you as expected or that you think is missing or confusing.
2 Likes
It definietely looks fantastic already 
.
Will certainly give it a try (and report back, if something occurs).
1 Like
This has pleasantly veered off course from the initial question/request for having an option in how the file name is displayed in the UI (which I still hope will have a settings option or some permanent way of changing the display)
That being said there is a this helpful forum post about Git Guidance and an incredible video (answered a lot of my questions) by @FlorianPircher with a step-by-step introduction of working with Git and .glyphspackage files → https://www.youtube.com/watch?v=1Pi0OZw2ZKo&t=16s
This looks absolutely fantastic, very well thought out and great tutorials! Is there any advantage in using Commit Glyphs over Light Table? (Sorry for hijacking the thread, feel free to delete)
Commit Glyphs has a visual comparison in the commit window which is still missing in Light Table. Commit Glyphs also splits the glyphs of a .glyphs file into separate diffs and lets you stage them individually; in Light Table, you need to work with .glyphspackage for that.
In general, Light Table does not handle .glyphs files well at the moment, while Commit Glyphs does not work with .glyphspackage at all. I think .glyphspackage is much better anyway (just look at the text next to my user name), which is why I prioritized it for now.
I split the posts into a separate topic, so it should be more organized now.
(also sorry for highjacking the original topic shortly).
I generally agree, but we still have performance problems with bigger files like Hangeul fonts when using .glyphspackage files over .glyphs files. Usually slower when saving.
(That problem for us is connected to what I reported before, where some of our .glyphs files automatically convert to .glyphspackage files. [But we can discuss that in the issue, not here].)
Just wanted to say:
glyphspackage = goodglyphspackage for large fonts = slow
At least currently.
Can you send me one of the files that is slower saving as package?
Thanks, Georg. Due to lack of capacities on our ends at the moment, let’s just ditch those .glyphspackage issues. The saving speed problem seems to be better by now (we still see the beachball, but that also happens with .glyphs files).
In case either of these 2 problems occurs again, I’ll report back from scratch and provide the files in that case. Until further notice, let’s check this off 
I just see that for bigger files, glyphspackage is much faster when autosaving. So if your file not faster of even slower than flat .glyphs file, I like to see what it’s doing.
Yes. But we cannot reproduce by now anymore. It seems to have resolved over the time since we first encountered that. So all clear until further notice (and if so, of course with file)