X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=EmgKYJagoy2nU7NaB8423KWsQ48mDcW1LyJ12dKK+DU=; b=TkM0Csxto4ix4ZHfE7iD/TQOB/ogmb6hhPYbtx+4xoFhInpTLyiksG/m/S6TBbMUeX I5cYreXSIKjyXp3yJpga5RevgnbDNTFtNRv8kTLV8t5uUQ4FsggwD38Kv6sYtSNpP7Z5 VOsHe5Ek3XxBjusNSiZRiHth+c8o2vQDnsY56bnKWRhHRx9NPGrqW6jsaiJ9i7FTTz4k QjHxPzsEfcZgEeSlnwpE6T3gfKYKarpYNktFkau5f5/us982yp4SPb7bE2rmuTPAny/p tb7cfnCd/IAE68erruvgY4rWUjIWDbjtGyEyZBbpW73hgjqhH0tVMksjWGx4eokHoXIB 1a6Q== MIME-Version: 1.0 X-Received: by 10.112.54.132 with SMTP id j4mr14541357lbp.84.1440301486520; Sat, 22 Aug 2015 20:44:46 -0700 (PDT) In-Reply-To: <55D8D8B8.7050907@jump-ing.de> References: <55D8D8B8 DOT 7050907 AT jump-ing DOT de> Date: Sun, 23 Aug 2015 03:44:46 +0000 Message-ID: Subject: Re: [geda-user] Antifork From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t7N3irHk018342 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 On Sat, Aug 22, 2015 at 8:16 PM, Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote: > Hello folks, > > for years I had and still have the impression that there is no shortage of gEDA/pcb developers. Actually, many talented people happily hack away on the project. However, for some magic reason, none of them does so in the official repo. Virtually all of them create forks. No surprise, their stuff is close to invisible. Work gets duplicated. Bugs are never completed. You name it. > > Enter antifork. I wrote a script which simply does the reverse. It pulls back all the branches in remote repositories into the official repo. ... wait ... not into the public official repo, yet, but your local clone of it. Forwarding such branches to the public repo is straightforward, simply do a 'git push origin '. > > Usage is simple. Like every well written script it reports usage hints when run with the -h argument. > > As it's not on the master branch, yet, it has to be grabbed: > > cd /path/to/pcb/repo > git checkout whatever-branch-you-like > git checkout LP1487761-antifork antifork/* > > Then you can antifork: > > cd antifork > ./antifork.sh -h > ./antifork.sh > > Suddenly you have all the remote branches right there in your repo browser. You can compare them, rebase them, add commits to bug reports, forward stuff to the public repo in a snap, actually resolving bugs. > > Even cleaning is possible: if you found one of the forked branches to be obsolete, simply add the commit hash of the last commit to the repo description file in antifork/, along with a 'ignorebranch' in front of it. 'clifton' has an example already. Then these fork tracking branches will be removed/ignored on the next run of antifork. > > What do you think? Good idea? I do hope collaboration picks up again. You are right in your motivations. We do need to pull in stuff from the various branches. I have been doing testing of Igor2's pcb-rnd. The more functionality that goes into that branch, the more I worry about project fragmentation. As cool as his branch is I really miss autotools build and opengl shading. It is nice to have a tool to do what you are describing but I fear merging code with out talking to it's authors. They most likely have reasons for not merging it other than "I was too lazy to submit a patch." It might just be "i wanted testing done." or "the mainline developer(s) drove me away back then." The problem is I suspect a lot of it is "This worked good enough for me to do X but not reliably enough for me to feel like it was ready for inclusion." We need a way to go down the branches one by one and 1. Ask their owner about them. 2. If the owner is missing in action do a review ourselves. > Markus > > -- > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. (FH) Markus Hitter > http://www.jump-ing.de/ -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/