Good point, actually.
Am 22. September 2017 11:08:15 MESZ schrieb Miguel Angel Ajo Pelayo <majop...@redhat.com>: >I believe it's better if each library type has a single directory on >the >top of the libraries repo, in a single branch. > >That would let you have branches like > >master >stable/4 >stable/5 >stable/6 later on, > >and point the specific versions of kicad to such branches, in a way >that an >old version of kicad would not explode if new features appear in >libraries >in a later version. > > >In that way, it's very easy to backport a change if the library is >still >backwards-compatible > >git checkout stable/4 >git cherry-pick <commit-id-on-stable/5 or master> >git push > > > >On Fri, Sep 22, 2017 at 11:05 AM, Miguel Angel Ajo Pelayo < >majop...@redhat.com> wrote: > >> Please don't use branches for that. >> >> Branches are to track separate development efforts or release >> cycles/stabilization. >> >> Using branches, while it's possible was not the intent when git was >> designed. >> >> If you do it that way, then you won't be able to use branches to >track >> libraries in different stabilization phases, etc. >> >> >> >> >> On Fri, Sep 22, 2017 at 10:51 AM, Bastian Neumannn < >> neumann.bast...@gmail.com> wrote: >> >>> I really like the idea of having one repo with all the .pretty >folders in >>> different branches. The master can have meta data about the >branches. >>> >>> That also gives the ability to manage library downloads as you can >>> download the branch as a zip. >>> >>> Using git for library management is ideally implemented as a plugin. >With >>> the ability to define own repositories as well. The library >downloader can >>> fetch the branch list and present a selection to the user to fetch >>> whatever the user want to fetch. >>> >>> zip files of the branches can be mirrored on other servers as well >for >>> the people not having access to github. >>> >>> Cheers, >>> Basti >>> >>> 2017-09-22 10:39 GMT+02:00 Simon Küppers <simon.kuepp...@rub.de>: >>> >>>> And by the way, this would be a feature that is completely new to >the >>>> market (correct me if I'm wrong). Git integration into eda >software. >>>> I only know of altium that has an svn interface and a proprietary >vault. >>>> The features both of which could be (at some point) realized using >git. >>>> Innovation is fun :-) >>>> >>>> The idea of modifying a footprint from the standard lib, and >generating >>>> a patch that could be directly send to the maintainers (maybe using >the >>>> very new library website) would make contributing very easy! >>>> >>>> Am 22. September 2017 10:13:49 MESZ schrieb Ingo Kletti < >>>> ikle...@htwg-konstanz.de>: >>>> >>>>> Hi, >>>>> >>>>> Am 22.09.2017 um 09:44 schrieb Oliver Walters: >>>>> >>>>>> [...] svn has the advantage of being able to >>>>>> pull selective directories from GitHub. You could present the >user with a >>>>>> list of which libraries they actually want to pull down >>>>>> >>>>> >>>>> So, just like JS (@tiger12506) I'm excited any time the git >integration >>>>> comes up for discussion. >>>>> >>>>> While I understand the initial focus on Github, it's just like >Simon stated: >>>>> >>>>> Why not just ask the user for a working directory and pull the >>>>>> libraries there using actual git? >>>>>> This has the obvious advantage, that anyone can use this not >only >>>>>> >>>>> with > github but also with his or her own local repository.. >>>>> >>>>> Without in-depth knowledge about git vs. git-plugin vs. svn: >>>>> >>>>> Will it be possible to use another repository besides Github? >>>>> >>>>> In our case, we require our students to maintain their project on >a >>>>> Gitlab server. This server also hosts the KiCad libraries that >were >>>>> created for internal purposes. ATM, it's not possible to just pull >the >>>>> latest version of the internal KiCad libraries from inside KiCad >>>>> >>>>> And it might not just be us. I think having a proper git >integration >>>>> could ease the library handling of many users. >>>>> >>>>> In the end, a proper git and/or svn integration would also open >the >>>>> possibility to directly handle version management of KiCad >projects from >>>>> inside KiCad. >>>>> >>>>> Regards, >>>>> >>>>> Ingo >>>>> >>>>> ------------------------------ >>>>> >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> Post to : kicad-developers@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : kicad-developers@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp