True, I see the problem with everything in one repo with branches. Maybe it was not a good idea after all.
2017-09-22 11:13 GMT+02:00 Simon Küppers <simon.kuepp...@rub.de>: > 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 > >
_______________________________________________ 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