Kicad own symbol merge strategies

[rob]

After having consulted How to merge library including lib and mod files, I’m still worrying about how to merge new or modified symbols into the current state of the git master branch.
Use case: Modifications and new symbols are created around early 5.x series, in an own branch of “at that time” git repository state. Current state (after a year of no kicad work): Kicad 5.1.7 and current git master library state (I did not “install” library packages). Symbol & footprint repositories are stored in /home/kicad/ (and also a user & group “kicad” is present to facilitate more than one workstation user).

I encounter severe difficulties of doing so via git rebase, and fixing the merge problems manually is a job that requires quite some consciousness and time… - especially if the common ancestor shows a library version 2.3, while both current git master & own branch show 2.4 upon the file start.
Hence I’m considering an alternative approach: Doing it via symbol copy using the symbol editor. But then I need a copy of the whole library in current master as well as my older branch state and have all of them accessible within the same symbol editor session. This would make sense especially for transferring modified components: Simple visual comparison is possible (of course at best with two instances of the symbol editor active).
The problem with this approach is the global sym-lib-table. I’d need an extra project specific sym-lib-table that adds the state of the own git branch.

In the end it seems to make more sense to copy all my modified and new components into a temporary symbol library file (referred to in the local project sym-lib-table) and then exit the symbol editor, switch to git master branch, start symbol editor again and then take care of transferring each symbol of the temporary library file.

Any suggestions resp. ideas about strategies?
And does the python utils package (schlib) offer support for this sort of work?

Note: the “current” (e.g. 5.1.7 lib) global sym-lib-table may differ from earlier sym-lib-table because of changes in library file names or deletions or added stuff. This may complicate merge matters…

[Rene_Poschl]

In general i would advise against changing the official library except for the purpose of contributing to it. Personal assets are best held in personal libraries.

The reason is exactly the thing that happened to you. The official lib just moves on and you need to manage combining your changes with the changes on the official lib. So instead of putting your personal symbols into a temporary library maybe put them into a fully personal lib instead (otherwise the next commit on the official lib might just require yet another merge on your end).

I also kind of doubt you are really on the current master branch. After all the current master is already in the new file format of future version 6. Did you notice that the library moved over to gitlab?

[rob]

I’m aware of the problems associated with using the official library as the resource for schematic design. But git makes it quite attractive due to naturally lightweight branches. Then, effectively there is no difference between using a copy of a git library snapshot (or as installed from a bundle package). But in this case I’d also prefer to add new symbols in a (global) library file that represents the family the symbol ‘belongs’ to. Regardless the question: contribute to upstream or not, the branching workflow is clearly preferable!
BTW: Interesting to take notice of visual diffs through a project, referred to on your Project and libary setup for sharing and collaboration (KiCad version 5), “Further reading” -> https://jnavila.github.io/plotkicadsch/.

In the case of footprints, merging is not such a problem because every footprint is in an individual file.