anchor.diff:  other tweaking::
   You can tweak the `publish_html.sh` script to use other features of giblish/asciidoctor, such as docid's, docinfo support and others. To do this, change the flags and arguments used to invoke giblish from the `publish_html.sh` script accordingly.
   
  -== Deploy using Jenkins
  -
  -This setup adds a Jenkins (or similar build orchestrator) installation so it is more tools to setup but offer more flexibility and is probably more 'production friendly'.
  -
  -.Deploy using Jenkins
  -image::deploy_with_jenkins.svg[]
  -
  -=== Sequence for rendering documents
  -
  -The following image shows how the sequence from user commit to rendered documents.
  -
  -image::Render Documents.png[]
  -
   === The setup process for Jenkins and git hook combo
   
  -bla bla ö
  +TBD
   
   [appendix]
   [[post-update-hook]]
  
positive.code: 
  To describe how to use giblish as a tool for creating a static web site with documents that are automatically generated each time a contributer push changes to a git repo.
  
  This text covers two deployment scenarios; one using git hooks only, and one using a combination of git hooks and Jenkins. It has only been tested on Linux servers (Ubuntu). Most of the tools and scripts should work on a Windows server as well but might need some tweaking and is, again, not tested.
  
  === A note about permissions and security
  
  These instructions does not give any advice on setting up permissions in a way suitable for your use case. You should however, give this an appropriate amount of consideration. You need to set the permissions so that the relevant tools and scripts can perform their expected tasks without being security holes of your server. You might want to consider setting up specific user accounts/groups to achieve this but this is outside the scope of this text.
  
  === A note about server side git hooks
  
  git supports hooks in several parts of the sequence of getting changes committed and pushed to a remote repo. This feature is used in both scenarios below to kick-start the HTML document generation when someone pushes a change to the git repository.
  
  For details on git hooks see https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks[this doc].
  
  [[common_setup]]
  === Initial setup
  
  These steps are common to both deployment scenarios below.
  
  giblish setup::
   . Install ruby on the _Server_ (a version no more than 18 months old)
   . Install giblish on the _Server_ using `gem install giblish`
  
  git and gitrepo setup::
   . Install git on the _Server_.
   . Setup the *bare* _Master Repo_ on the _Server_ by either.
   .. Copy a bare repo you already use to the _Server_ file system.
   .. Init a new repo using `git init --bare <your_repo_name>` somewhere on the _Server_ file system.
  +
  NOTE: If you start with an empty, bare _Master Repo_ on the _Server_, it is a good idea to directly clone it to your local machine, commit some content to the 'master' branch and push the result back to the _Master Repo_. An empty, bare repo does not even contain a 'master' branch from the start and this can lead to some edge cases that complicate things.
  
  == Deploy using git hooks only
  
  This requires the least number of installed components to work. An overview of the scenario is given below.
  
  
negative.code:  * The hook and publish scripts provided with giblish runs *syncronously* at each push from a _Doc Writer_ to the _Master Repo_. The time it takes to generate the HTML docs from the adoc source will thus be added to each push to the _Master Repo_.
   * You need to manually setup the _Staging Repo_ on the server and this is a bit more 'hackish' than letting a build orchestrator tool handle this.
   * The `publish_html` script provided with giblish only uses the currently checked-out branch on the _Staging Repo_ (typically 'master') to generate the HTML docs. It is non-trivial to add multiple-branch generation to the provided script.
  
  === Using Jenkins / git hook combo
  
  This setup adds a Jenkins (or similar build orchestrator) installation so it is more tools to setup but offer more flexibility and is probably more 'production friendly'.
  
  .Deploy using Jenkins
  image::deploy_with_jenkins.svg[]
  
  ==== Sequence for generating documents
  
  The following image shows how the sequence from user commit to generated documents.
  
  .Sequence diagram for generating docs from adoc
  image::Render Documents.png[]
  
  == The setup process
  
  [[common_setup]]
  === Initial setup
  
  These steps are common to both deployment scenarios below.
  
  giblish setup::
   . Install ruby on the _Server_ (a version no more than 18 months old)
   . Install giblish on the _Server_ using `gem install giblish`
  
  git and gitrepo setup::
   . Install git on the _Server_.
   . Setup the *bare* _Master Repo_ on the _Server_ by either.
   .. Copy a bare repo you already use to the _Server_ file system.
   .. Init a new repo using `git init --bare <your_repo_name>` somewhere on the _Server_ file system.
  +
  NOTE: If you start with an empty, bare _Master Repo_ on the _Server_, it is a good idea to directly clone it to your local machine, commit some content to the 'master' branch and push the result back to the _Master Repo_. An empty, bare repo does not even contain a 'master' branch from the start and this can lead to some edge cases that complicate things.
  
  
  === Setup process for git hooks only
  
  