Opinions on removing GitHub plugin

We are currently discussing the removal of the GitHub plugin from KiCad library management. Didn’t know that KiCad had a GitHub plugin? Then this will not affect you at all.

We’re looking for users that actively use the GitHub plugin for their professional work and would be affected by its removal.

If this is you, please reply here with how you are using the plugin and we’ll see what we can do to support your use case going forward.

The gitlab discussion is on:

The github plugin is now removed from 5.99.

Gosh, that’s fast.
I expected this message to sit here for a few weeks to give more people time to respond.
There are not many users who check the forum daily.

Personally I have never liked or used this plugin, and quite dislike it for the default libraries.
I can imagine some useful use for personal libraries with this plugin, or group collaboration.

For personal libs it is even worse. The github plugin is one way. So you would need to have the libs as a normal local git clone to change something. So i would assume everyone who uses github for libs will therefore use a local clone and connect kicad to that clone (is then a normal local lib as far as kicad is concerned).

Maybe it is (was?) possible for a “project leader” to maintain some git repositories, and for the rest of the team to automatically sync with this, without the rest of the team needing to have any git experience.

But I agree it’s a convoluted example.

The plugin is removed but we can always add it back if there are late responses to this message.

Please note that I am only interested in responses from people that actively use this feature for professional KiCad work, not hypotheticals

4 Likes

Today I did a bit of research about junction-dots-and-hop-overs-comparison-of-programs and during that research I accidentally found a company that uses the git plugin:
https://copenhagensuborbitals.com/new-eda-tool/

One of these [Reasons for switching to KiCad] is the ability to work with symbol and part libraries that are centrally located on a GIT server. Thus we do not have to synchronize local libraries when exchanging designs at different stages of development, and can also ensure some standardization of our locally defined components

[ Edit: ]
I e-mailed Copenhagen Suborbitals via their contact form with a link back to this topic, maybe we’ll hear from them.

Perhaps they can be convinced that the Git plugins is only loosely related to effective library management using Git and more akin to using a mule-drawn car.

It cannot told by reading that article whether they actually mean the plugin, or just the generic capability of using git easily with plain text libraries.

1 Like

True. I guess I just inferred that from this thread’s title :smiley:

It’s hard to tell from that announcement if they use it, but the main limitation is that if they wanted to push changes back to the server it would not be useful. The GitHub plugin was only one way (download from GitHub), and was also fairly closely tied to GitHu, so if they wanted an internal git server or the ability to push changes back up, they probably aren’t using it and instead are just saying the text-based library files make git easier to use with it.

Did the github plugin ever work with symbols? I thought it was only for footprints.

No, it was never added for symbols, only footprints. There is an open MR where someone wants to add a version for symbols though.

I mainly ask because the quoted text above states they use it for symbols so i think @eelik might be correct here.