Using git directly in a plugin would also make the git library a
dependency to build KiCad which in not without it's own set of issues.
On 8/17/2015 3:39 PM, Matthew Beckler wrote:
> Hi Andy,
>
> What you say makes sense. For the purposes of this discussion, git vs
> svn is irrelevant. I also pre
Just my 2c worth but that 'huge history' problem can be solved with
using the
"shallow clone" capability of git.
i.e. git clone --depth 1
Also, I think that all the individual repositories could be combined
as sub modules of a larger master repository and then you just clone
a single repositor
On 8/17/2015 3:26 PM, Andy Peters wrote:
>
>> On Aug 17, 2015, at 12:05 PM, Wayne Stambaugh wrote:
>>
>> If someone wants to write a git plugin, I'm sure some users would find
>> it useful. I'm not sure most users will want to learn git to maintain
>> their footprint libraries even though it's a
The github API is used to get the list of all repositories on the
KiCad group on github. git alone cannot do that.
However the zips from github are requested instead of checking out the
repo via cloning. Theres definitely arguments for cloning vs not. One
of the annoyances I see is some repos can
"A vendor neutral git API"
Yeah, a git executable client.
I'm not sure why it wasn't made to use a git client in the first place.
I like the idea of KiCad being smart about retrieving the footprints
from github, I'm just not sure why it needed to use the github APIs that
only work with github.
On 18 August 2015 at 07:39, Matthew Beckler
wrote:
>
> Hi Andy,
>
> What you say makes sense. For the purposes of this discussion, git vs svn
is
> irrelevant. I also prefer to keep all my kicad libraries in an svn/git
repository
> and just have to remember to "svn up" / "git pull" on each machine
Hi Andy,
What you say makes sense. For the purposes of this discussion, git vs svn
is irrelevant. I also prefer to keep all my kicad libraries in an svn/git
repository and just have to remember to "svn up" / "git pull" on each
machine I use. As you said, this requires no support from KiCad except
> On Aug 17, 2015, at 12:05 PM, Wayne Stambaugh wrote:
>
> If someone wants to write a git plugin, I'm sure some users would find
> it useful. I'm not sure most users will want to learn git to maintain
> their footprint libraries even though it's a good thing. The gihub
> server implementation
If someone wants to write a git plugin, I'm sure some users would find
it useful. I'm not sure most users will want to learn git to maintain
their footprint libraries even though it's a good thing. The gihub
server implementation was written because KiCad's libraries are
maintained on github whic
I don't really have any stock in this, but *yes* to what this guy said.
On 8/17/2015 2:52 PM, Matthew Beckler wrote:
It seems very strange to target our software at specific
implementations of git front-end websites. It seems even stranger to
suggest to end users to install a web server to act
It seems very strange to target our software at specific implementations of
git front-end websites. It seems even stranger to suggest to end users to
install a web server to act as a proxy to improve performance.
It seems like a simpler approach would be to support local git repositories
in the fi
Parameters (or properties as they are defined internally) are passed
defined in the footprint library table. They are simple key=value pairs
that are passed to the plugin defined by each footprint library table
entry. The person that wrote this code thought that it would be more
effort to code a
A parameter would work. I am not familiar with how to define new
environmental variables in the code and what you would want it to be called.
On Aug 13, 2015 8:27 AM, "Wayne Stambaugh" wrote:
> The next obvious question is what happens when "git" is part of the
> server name and the server doesn'
Adam,
I've already contacted Dick and he's looking into it. He has already
considered using a gitlab server so I'm guessing that he already has a
fix in mind. I expect he will send me a patch within the week. I
suspect that it's will not be a big patch and will be fairly low risk so
it shouldn'
The next obvious question is what happens when "git" is part of the
server name and the server doesn't follow the same zip file path
semantics that gitlab does? This is my concern and the concern of the
person who wrote the github code. This patch seems very specific to
gitlab rather than a gener
Gitlab uses different URLs for zip file downloads. Rather than
/zip/master the URLs are of the pattern
/repository/archive.zip. There are similarities in the two APIs,
but they are not the same.
The URL cannot be as in the kicad code that handles non github
servers; that points to the project mai
Please help me understand the purpose of this patch. Are you saying
that the github plugin does not work when KIGITHUB has the properly
specified URL and gitlab is configured properly? What's different
between gitlab and github access that necessitates this change? I
realize that it's a minor ch
Thanks, I really hope this can get into the stable release. It is the only
thing holding us back from using kicad at the company I work at.
Ian
On Aug 8, 2015 7:09 PM, "Adam Wolf" wrote:
> I think this is very good.
>
> Adam Wolf
> On Aug 8, 2015 5:37 PM, "Ian Roth" wrote:
>
>> This allows user
I think this is very good.
Adam Wolf
On Aug 8, 2015 5:37 PM, "Ian Roth" wrote:
> This allows users to host the footprint libraries on a local gitlab
> server in case there is no access to github.
>
> I know this patch has the potential to be controversial because the code
> in the plugin is supp
This allows users to host the footprint libraries on a local gitlab server
in case there is no access to github.
I know this patch has the potential to be controversial because the code in
the plugin is supposed to be as generic as possible and that the server
should change. I would like to counte
20 matches
Mail list logo
