kicad-developers team mailing list archive

[Bastian Neumannn <neumann.bastian@xxxxxxxxx>]

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.kueppers@xxxxxx>:

> Good point, actually.
>
>
> Am 22. September 2017 11:08:15 MESZ schrieb Miguel Angel Ajo Pelayo <
> majopela@xxxxxxxxxx>:
>>
>> 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 <
>> majopela@xxxxxxxxxx> 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.bastian@xxxxxxxxx> 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.kueppers@xxxxxx>:
>>>>
>>>>> 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 <
>>>>> ikletti@xxxxxxxxxxxxxxxx>:
>>>>>
>>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>