Reworked Git History.

[da2ce7]

This Issue details the work I have undertaken to improve the history and structure of the Gnofract 4D repository.

I have completed the following tasks:

1. Rewritten the Gnofract 4D History on-top of the Ancient cvs history found on Sourceforge.
2. Rewritten the Gnofract 4D History with corrected names and email addresses.

Please see:
https://github.com/da2ce7/fract4d-gnofract4d/tree/reworked_master

3. Create new 'Library', 'Documentation', and 'Website' repositories; with extracted history from main repository.

Please see:
https://github.com/da2ce7/fract4d-library/tree/reworked_master
https://github.com/da2ce7/fract4d-documentation/tree/reworked_master
https://github.com/da2ce7/fract4d-website/tree/reworked_master

Details:

I have created a repository containing a set of scripts that automate conversion process. (allowing me to be more confident that the conversion went successfully).
https://github.com/da2ce7/fract4d-reorganisation_helpers

Finally, I have a helper repository for the cvs to git conversion:
https://github.com/da2ce7/fract4d-reposurgeon_conversion

I am happy to either walk a member of the fract4d organization through the process of verifying and applying to the main repository; or; if given permission; I can attempt the formal conversion myself.

Please have a look at the previous issue (now closed) for more information: #57

[edyoung]

Cameron, thanks for working on this. As I mentioned before, I'm a little surprised anyone cares about the SourceForge prehistory of the program, but it's cool to see commits I checked in 20 years ago ;-)

If you would like to take on updating the official history as mentioned, please feel free. Sent you an invite.

Regarding creating extra repos:

I also created a fract4d/formulas repo containing (as a starting point) the orgform formulas. I don't have a strong view on which one to use, but I don't think we need both. Any thoughts?

On the docs and website, one thing to consider is that the docs contain some bits of info which are autogenerated by createdocs.py based on the command-line args and keyboard shortcuts available in the code. If we maintain the docs in an entirely separate repo that may be a bit more complicated to do (though there are ways to deal with it ranging from git submodules to just maintaining that data by hand). The docs are also installed on to an end users machine when they download a release or clone the repo, and I'd like to not make that any more complicated. My own thought is there is not a huge benefit to splitting out the doc and website repos at this point.

FYI I have been tinkering in the background with updating the docs to be in Markdown and the site to be generated using jekyll or hugo, though I find both of them a bit overcomplicated.