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
