X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f Date: Sat, 16 Jan 2016 15:11:17 -0500 Message-Id: <201601162011.u0GKBHYG028053@envy.delorie.com> From: DJ Delorie To: geda-user AT delorie DOT com In-reply-to: <569A9AD3.9060306@iee.org> (geda-user@delorie.com) Subject: Re: [geda-user] LP1532611 (modular fie formats) fixes References: <56982D5A DOT 1020706 AT prochac DOT sk> <569A2DAC DOT 9070200 AT prochac DOT sk> <569A3280 DOT 3030704 AT iee DOT org> <201601161912 DOT u0GJC8Fs025943 AT envy DOT delorie DOT com> <569A9AD3 DOT 9060306 AT iee DOT org> Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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. > 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.