Mail Archives: geda-user/2016/01/16/15:35:30
On 16/01/16 20:11, DJ Delorie wrote:
>> But from where I'm sitting/standing .. where IS that one spot?
> Um, the master repo... Type "git branch -a" or "gitk --all" to see
> all the activity, or visit:
>
> http://git.geda-project.org/pcb/
>
>> The idea is not to create a platform for people to rail against one
>> another, its to see what other people are working on,
> Hiding your changes in a private repo on someone else's computer
> doesn't help others see what you're working on. Effective
> communication does. We provide various means of communicating, from
> playing in the main repo where others can track your activites, to
> mailing lists, bug trackers, and IRC. Still, it's up to you (the
> developer) to ensure your work doesn't get lost, regardless of how you
> store it.
>
>> Also, its transparent how to merge A's work with B and C and so
>> forth .. at least in my eyes ..
> Merging emailed patches with git has always been a sore spot for me.
> I'd rather have patches in one repo where they're easy to
> click-n-merge.
Patches and email is very last century .. we're all not-quite
point-click .. but this is where gitk and web interfaces really make the
job so much easier. Pull requests really are just an extension of that
.. where a developer can say "hey, done this, wanna take a look" .. that
way the onus is moved from developer to integrator .. kinda thing.
I will clone the central repo, but for me as a newcomer, its very hard
to see who's working on what where. And onwards from that .. what's
literally someone's playground branch, and what's serious development code.
>> both git and github, but I can really see the power of it, and its
>> interface, although no reason why the command-line git tools don't
>> complement it either.
> I've been struggling with git for a long time now, and the main
> problem I have is that there are TOO MANY ways to do any one task.
> It's like having a box of legos - you can build anything, but building
> anything is hard because you always have to start from scratch. I'd
> rather have a few tools that limit people to well-understood paths, so
> that managing patches is more about the patch and less about the
> managing.
>
> If there are 9 different ways to do something in git, you only have to
> learn one - but I have to learn all 9 because I have to be able to
> manage contributions from 9 different people who have learned 9
> different ways of doing things.
>
>> As it's free to use, and I have nothing to hide, this would
>> obviously be my platform of choice (either GH or bitbucket I've
>> used) for my code development (and already is in a couple of cases).
> Heck, I ran all of DJGPP for 20 years with just CVS. Flexibility is
> not always a benefit.
Well, I've come from a subversion -> Mercurial migration, and apart from
svn being far too limiting, I've got used to the Hg workflow. Although,
I've hit edge cases where I make a mistake, and undoing/repairing the
problem is much more than Hg can handle. I'm learning git, and yes, like
many things (perl for example) its a toolkit .. it depends a lot how you
use it.
As I'm inducted into the gentoo 'fold' there is a strict procedure for
contributors to follow, including a script-based QA procedure (it checks
a template for a set of basic rules) then its up to the authority to
review, comment and merge if they see fit. There is no reason why a
similar 'procedure' (needn't be totally draconian) couldn't be put
together for geda/pcb development, surely?!
My intention is not to try to break/change/fix what is set up already ..
just suggest some ways to lubricate the cogs of the machine. Clearly
there are some road-block issues, and only a collective will to change
them will ever address those.
- Raw text -