DokuWiki Installer


This page assists in the first time installation and configuration of Dokuwiki. More info on this installer is available on it's own documentation page.

DokuWiki uses ordinary files for the storage of wiki pages and other information associated with those pages (e.g. images, search indexes, old revisions, etc). In order to operate successfully DokuWiki must have write access to the directories that hold those files. This installer is not capable of setting up directory permissions. That normally needs to be done directly on a command shell or if you are using hosting, through FTP or your hosting control panel (e.g. cPanel).

This installer will setup your DokuWiki configuration for ACL, which in turn allows administrator login and access to DokuWiki's admin menu for installing plugins, managing users, managing access to wiki pages and alteration of configuration settings. It isn't required for DokuWiki to operate, however it will make Dokuwiki easier to administer.

Experienced users or users with special setup requirements should use these links for details concerning installation instructions and configuration settings.

For security reasons this script will only work with a new and unmodified Dokuwiki installation. You should either re-extract the files from the downloaded package or consult the complete Dokuwiki installation instructions

driven by DokuWiki powered by PHP
Working with Git Submodules in MantisBT [Mantis Bug Tracker Wiki]

User Tools

Site Tools


Working with Git Submodules in MantisBT

Some 3rd party libraries are stored and maintained in the MantisBT repository using Git Submodules.

This setup requires some special handling when initializing the repository and when switching branches, especially to and from branches which do not (yet) have submodules in it.

The purpose of this page is to provide basic instructions to easily deal with commonly encountered issues.

Initializing the Repository

This is covered in the MantisBT Developer's Guide.

@@@TODO - update this when updated docbook has been merged with Master. Until then, copy/paste follows:

Switching Branches

With Submodules --> No Submodules

Checking out a branch with Submodules when the current branch does not have them.

$ git status
# On branch WithSubmodules
nothing to commit, working directory clean

$ git checkout NoSubmodules
error: The following untracked working tree files would be overwritten by checkout:
	(list of files)

Solution 1

WARNING: this will cause the loss of all changes in any of the submodules that have not been pushed upstream. Only do this if you are sure that you don't have any pending modifications.

First we force checkout to ignore changes, then we remove all untracked files.

$ git checkout --force NoSubmodules
warning: unable to rmdir library/adodb: Directory not empty
warning: unable to rmdir library/phpmailer: Directory not empty
Switched to branch 'NoSubmodules'

$ git clean --force
Removing library/adodb/.gitattributes
Removing library/phpmailer/.gitignore

Solution 2

This is slightly more complex but safer alternative, recommended if there are changes to be kept in the submodules.

Move the submodules directory to a temporary location, e.g. /tmp

$ sed -rn "s/^.*path\s*=\s*(.*)$/\1/p" .gitmodules |xargs -I{} mv {} /tmp
$ git checkout NoSubmodules
Switched to branch 'NoSubmodules'

When switching back from the older branch, the submodules directories will be empty. At that point you can either

  • Update the submodules to reclone them (in which case earlier changes will be lost)
    $ git submodule update
  • Restore the directories previously moved to /tmp back into the empty directories, e.g.
    sed -rn "s/^.*path\s*=\s*(.*)$/\1/p" .gitmodules |xargs -n 1 basename |xargs -I{} mv -v /tmp/{} library

No Submodules --> With Submodules

Checking out a branch without Submodules when the current branch has them.

$ git status
# On branch NoSubmodules
nothing to commit, working directory clean

$ git checkout WithSubmodules
M	library/adodb
M	library/phpmailer
Switched to branch 'WithSubmodules'


Use the following command to reset all Submodules to the state of their respective recorded commit:

git submodule foreach git checkout -- .

Submodules --> Submodules

Checking out a branch with Submodules when the current branch has the same submodules but pointing to a different commit.

For example, branch SubmodulesNew has an updated ADOdb library:

$ git status
# On branch SubmodulesOld
nothing to commit, working directory clean

$ git checkout SubmodulesNew
M	library/adodb
Switched to a new branch 'SubmodulesNew'


Just update the submodule(s)…

$ git submodule update 
Submodule path 'library/adodb': checked out '<commit sha>'

Updating a Library's submodule

This section describes the process to update a submodule when a new version of a library has been released upstream.

Updating via an external repository

The example given here are for the ADOdb library, but the same logic should apply (possibly with some variations) to other submodules as well. We assume that you already have a local repository configured with the appropriate remotes (upstream for the library's official repository and origin for the MantisBT fork)

  1. Update the library's fork in the mantisbt Github organization
    • Get the latest from upstream
      cd /path/to/local/adodb
      git fetch upstream
    • Optional: update the master branch
      git rebase upstream/master master
    • Update the branch
      git checkout mantis-1.3
      git merge v5.19
    • Resolve any conflicts
    • Push changes to the fork
      git push origin --tags master mantis-1.3

      Note that it's not strictly necessary to push the tags or the master branch. Having the tags allows a better description of the submodule's current commit when running git submodule (see example at the end of this section)

  2. Update the submodule
    • Go to your local mantisbt repository and update it
      cd /path/to/mantisbt
      git checkout master
      git pull
    • Go to the submodule's directory and checkout the branch
      cd library/adodb
      git checkout mantis-1.3
      git pull
      cd ..
  3. Update README.libs to reflect the new version
  4. Commit the changes
    git commit -a

At this point, checking the submodules' status should give you a “clean” list , e.g. (notice no '+' sign in column 1)

$ git submodule 
 9346d288a1b7f7a50cc35b6a0e56d29e9d000ecf adodb (v5.19-6-g9346d28)
 75a4e5595c0dfcb2e2e1e41b9ba2282828d3f292 disposable (release-2.0.0-3-g75a4e55)
 cb771839899d9f6be9f1268b986c30327ff1199b phpmailer (v5.2.6-2-gcb77183)
 41beaddd279c695aacb63407e2c98b04b7eaff51 securimage (heads/mantis)

Updating from within the submodule

It's worth mentioning that step 1 above can also be performed straight from the submodule itself (see example below for phpmailer), provided of course that the remotes (origin and upstream) have been properly configured.

WARNING: if you update the submodule in-place, it is critical that you actually push the changes to origin otherwise the other developers will have an corrupted repository with missing commits when they pull the changes.

  • Update the submodule from upstream
    cd library/phpmailer
    git fetch upstream
    git rebase upstream/master master
    git checkout mantis
    git merge v5.2.7
    # Resolve conflicts
  • Push changes to the fork - don't forget this step !
    git push origin --tags master mantis
    cd ..
  • Edit README.libs
  • Commit the changes
    git commit -a
mantisbt/git_submodules.txt · Last modified: 2014/04/30 13:00 by dregad