I am new to penpot (FOSS ftw). I want to learn more about the .penpot files. I know many applications often export these objects as gzip-compressed JSON files, but I tried investigating this:
~/Downloads $ ls
~/Downloads $ mv demo-01.penpot demo-01.gz
~/Downloads $ gunzip demo-01.gz
gzip: demo-01.gz: not in gzip format
~/Downloads $ echo $?
Running strings or file on the file doesn’t return much. What I’m trying to investigate is whether the .penpot will fully represent the project state and if checking it into VCS (e.g. git, etc.) will maintain file integrity.
Hi! The .penpot file is a binary format for improve the importation process. You can export also in zip, that gives you all the internal info: svgs and json.
So, yes, the .penpot file represent the project state, but in a non-human-readeable form. And you can check it to git, and check out again. The problems will be if git needs to generate diffs and merges: git cannot generate meaningful diffs, or merge binary files in any way that could make sense. So probably not the best idea to check in .penpot files to be updated simultaneously for different people.
Yes, I think that what you are looking for are the .zip files you get when you “download standard file”. Anyway, if you want VCS diff functionality, you will need to extract them before commit, and zip them again prior to import into Penpot.
Probably this is not much convenient. We are investigating better ways of do version control with Penpot, but it’s not a trivial problem and there is much to think about before we have a detailed plan.
I understand the plausibility for many (developer) teams to check in content to .git
However, git’s focus is clearly on text-based code and it is made for developers (and even many developers have trouble with using it well).
There are jokes about the many files that designers keep around and distinguish with ad-hoc naming schemes. However, this method has advantanges in practice: One can easily open several files at the same moment, compare, show to others, print, copy content between them without a lot of effort, just by the virtue of knowing your OS file manager (and that not even well); a practice that I find myself even doing with code and struggle to do efficiently with using git.