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:	<CAM2RGhSZ1vi_DFKqZdZYxhto4ZaXLLscBt5m5kk+PH2ZoYW_vw@mail.gmail.com>
Subject:	Re: [geda-user] Antifork
From:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
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

On Sat, Aug 22, 2015 at 8:16 PM, Markus Hitter (mah AT jump-ing DOT de) [via
geda-user AT delorie DOT com] <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 <branch>'.
>
> 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/

- Raw text -