Htdocs Split

Htdocs Conversion Notice

For some time now the gnucash-htdocs repository has been used to store both the website and a compiled version of our documentation in html, pdf, ebup and mobi formats. The problem with this was that the compiled documentation is pretty large. The repository was finally over 800Mb in size and increasing with each release. That meant that over time a simple clone of the repository would cost increasingly more bandwidth, diskspace and users time.

People that wish to work on the website don't need this compiled documentation so the large download was an unnecessary burden. We have decided to fix this by splitting off the compiled documentation into a separate repository, which is only relevant for a release manager. After the split, the gnucash-htdocs repository has been regenerated without the docs history.

Update your clones and forks

If you have your own clone of the gnucash-htdocs git repository you will have to reclone the new repository if you want to enjoy the smaller footprint. If you have local changes you'll want to preserve them. So instead of deleting the directory rename it. For the examples we'll call it gnucash-htdocs-old, and we'll clone into gnucash-htdocs-new. That's just to make sure we don't forget which is which. After the import process is complete, you can remove gnucash-htdocs-old and rename gnucash-htdocs-new.

You've been assiduous about always using git pull --rebase, right? No? You've got changes mixed into master? No matter. rebase to the rescue: (I'm using master as an example here, but it could be any tracking branch.)

 cd gnucash-htdocs-old
 git pull --rebase
 git branch -m master foo #This is your new feature branch. You can call it anything you like
 git branch -t master origin/master
 git rebase master foo

There. Now all of your changes are in a nice feature branch. You might have to reconcile some conflicts, but better sooner than later, eh? If you already have feature branches -- we'll use foo for our example -- just make sure that it's up to date with its tracking branch:

 git checkout master
 git pull --rebase
 git rebase master foo

Now you're ready to export your changes. Do this one feature branch at the time. Create a set of patches for your feature branch:

 cd ../gnucash-htdocs-old
 git checkout foo
 git format-patch --stdout master > ../foo.mbox

And import your branch foo into the new repo:

 cd ../gnucash-htdocs-new
 git checkout master
 git checkout -b foo
 git am ../foo.mbox

That's it. Repeat for each feature branch and tracking branch. When you're done and really, really sure that everything is properly set up, you can delete gnucash-htdocs-old and any foo.mbox you created.

Note: When you run git checkout master in gnucash-htdocs-new, git should respond with

 Checking out files: 100% (1247/1247), done.
 Branch master set up to track remote branch master from origin.
 Switched to a new branch 'master'

If it doesn't, then it may have gotten confused. If

 git log --oneline -n 10

doesn't produce the expected results,

 git branch -D master
 git branch -t master origin/master

To get the proper master branch.

Github Forks

If you have made a Github fork you will need to make sure that your local repo is current and then delete the fork and re-fork the regenerated repository, then proceed according to the instructions above, finally pushing any new branches back to your Github fork.