I keep setting up hierarchical schematics and saving the toplevels and everything. Whenever I commit to my Gitlab and merge, all of my project work dissolves. I close and reopen projects to complete blanks; some of the lower underlying sheets are recoverable but never the base project schematic. I’m using Win10, the most recent stable KiCad, and the SnapEDA plugin.
I don’t know if it has to do with CRLF->LF conversions done by Git or some terrible support on Windows. I don’t really understand why I keep running into this issue.
My files seem fine from the .bak files but I can’t recover them manually. Whenever I attempt to open them I get 4:23:18 PM: file ‘C:\Users\gamer…_rev0.sch-bak’, line 1: ‘=’ expected.
4:23:18 PM: file ‘C:\Users\gamer…_rev0.sch-bak’, line 2: ‘=’ expected.
etc., etc., for all of the sheets involved.
Are there any known bugs with KiCad and Git? Are there better version control environments to use KiCad with? I don’t understand how this could even be an issue. I have KiCad saving automatically every 3 minutes, and yet every time I save, close, and reopen my project everything seems to disappear or only remain in the .bak file.
Any insight on this would be really great. I realize this isn’t the first time someone has run into this.
The SnapEDA plugin shouldn’t provide any issue; it adds the part to the local library cache and actually helps with the version control.
I’m guessing it’s some issue with CRLF->LF conversion but I’m not sure how the software handles that.
I am really frustrated that it consistently clears my top sheet, and there are no options to manually recover the project. This has wasted nearly 16 hours of my time.
Is there anyone who has experience with Git versioning in Windows environments for KiCad projects?
Just to rehash my workflow, I save my project manually, commit it, push it to master, merge it on Gitlab’s website. All of the work looks correct on the repo. When I reopen the sheet, everything is gone. I can manually add hierarchical sheets back and just name them the names I did when I first created them, those recover successfully.
It’s unbelievable that this occurs. Is there just not any tolerance for CRLF/LF? If so, well, why even release a Windows version.
I use git on windows with kicad for all my projects and have no issues.
CRLF shouldn’t be an issue at all because kicad doesn’t care what line endings are used, it can open linux files just fine. But just in case you can set this option in git config and git will keep crlf in your local files: git config --global core.autocrlf true
You have messed up what is checked into git somehow. But even so it shouldn’t make your files in local checkout unreadable right after you save them, git doesn’t change your files unless you instruct it to do so.
Problem may be here, kicad files don’t merge in any meaningful way. Using git merge is ok if branches touch different files. Can you link your gitlab project?
You can try to replicate your issue with dummy project that doesn’t contain any trade secrets and share that if issue persists.
In general here is a .gitignore from one of my projects showing files that are not to be included in git repo, everything else should be included (you can browse the repo).
In short: VC systems with KiCad are good for keeping version history and using a remote repo gives extra backups, but all reasons for existence of modern VCS, especially decentralized distributed development (easy merging, cherry picking etc.), are nullified. Only push/pull works and even that only with good communication. Git lacks file locking and having simultaneous access to same repository from several locations can ruin your day with KiCad if you’re not careful. I have ruined my day by pushing from one machine and then continuing from another without remembering to pull first. All changes from one or another are lost.
As qu1ck said, we are talking about changes within one file; each file is independent from others as far as merging goes.
I get that. I wasn’t diffing during merges but just removing the old ones.
I think the issue probably lied in the CRLF-> LF transition. Why that still remains a thing is not really up to KiCad to worry about, I just wish there were better options.
I doubt it is. The format is not line oriented, line endings are white space as far as the parser is concerned. You should have a look at what happens to the contents of the file after a git operation with an editor to see what the issue is. Since you can’t post your files, try it with a sample public project.
Git has many options for handling the *&^%$#@! CRLF stuff. A short but usefull description of handling crlf is on:
git is also extremely configurable, either globally, per project, or even on file basis when needed. For intricacies of such things the best source is probably the GIT manual itself, or some other good book about GIT.
But are you sure its a CR/LF issue? If you want to analyze the problem further, then start by comparing differences between a good and a maimed file.
I’ll probably have to go through and see if there was a merge or some other kind of corruption that caused it. I just don’t understand why it would gimp the toplevel sheet and leave all the sublevels (and their sub-sheets) intact. I can’t seem to reconcile that in my head.
Kicad files and git are <3 as they are ASCII. This however doesn’t mean the full power of git can be utilized since it is a structured file not sourcecode.
Working on a per-sheet basis and treating a single change in a sheet as a total file change is the safest way
–edit–
Mentors collaborative work means multiple people can work on a schematic BUT it locks access at sheet level due to the havok this can cause.
Layout … This is locked to per board per user.
Basically the atomic level that can be worked in has to be a higher level that software sourcefile due to how the data is structured