From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: RFC: Creating a new org-contrib.git repository Date: Mon, 11 Mar 2013 22:56:50 +0100 Message-ID: <87ehflob19.fsf@Rainer.invalid> References: <874ngmgqfg.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:36946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFAiV-0005HV-Da for emacs-orgmode@gnu.org; Mon, 11 Mar 2013 17:57:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFAiT-0003YX-E7 for emacs-orgmode@gnu.org; Mon, 11 Mar 2013 17:57:11 -0400 Received: from plane.gmane.org ([80.91.229.3]:33313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFAiT-0003YJ-75 for emacs-orgmode@gnu.org; Mon, 11 Mar 2013 17:57:09 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UFAij-0004YQ-Nm for emacs-orgmode@gnu.org; Mon, 11 Mar 2013 22:57:25 +0100 Received: from pd9eb2da7.dip.t-dialin.net ([217.235.45.167]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Mar 2013 22:57:25 +0100 Received: from Stromeko by pd9eb2da7.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Mar 2013 22:57:25 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Bastien writes: > The advantage is (1) to separate Org's core logs (the one that are > further merged into Emacs) from the org-contrib.git logs, and (2) to > open org-contrib.git more widely, i.e., make it safe for anyone to > push commits there with no fear of doing something wrong in Org's > main repository. Also, remember that org-contrib.git would be open > for contributors without signing FSF papers first. I would like to remark that if these files should then move into core there will be lots of tedious work to ensure that all contributions are assigned to the FSF by that time. In that sense, org-contrib could become a dead-end rather than a staging area. If you only want wider push access to contrib/, then that could probably be done by a pre-commit hook. Or we could make it easier to pull from contributors' repositories by having the build system deal with submodules and requesting that contributions provide the necessary hooking in terms of a Makefile. That'd mean that those contributors who can't or don't want to assign copyright to the FSF keep their contributions in their own repositories. > On the technical side: does anyone know what incantations needs to > be done for this? I use git filter-branch (and its --tree-filter > option) from time to time but I'm definitely not an expert. What > we want at the end is: Rewriting the history so that it stays meaningful will not be easy and it will lose (or alter) information whenever a file moved between contrib and core in the past. This is not just a few incantations, you would have to write specific scripting to do this. I'd rather try to get as much contrib/ as possible into core and then re-assess what's left. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada