Re: RFC: Creating a new org-contrib.git repository

[Achim Gratz <Stromeko@nexgo.de>]

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