Import most FAQ items from old web site

Import most of the FAQ entries from our old web site.  A few outdated
questions have been omitted, many of the imported ones were updated in
one way or another, and the order of the development-related questions
has been changed.  Also, the phrasing of some questions has been
modified (just to make the headings shorter).

For the record, this is the original list of questions from the old web
site:

General
-------

* Who controls the Nagios Plugins project?
* What license is Nagios Plugins distributed under?
* Who owns the copyright for the Nagios Plugin code?
* Can I submit a patch to this project?
* Do you accept donations?

Compiling
---------

* ./configure appears to hang
* check_ldap, check_radius or check_pgsql don't compile even though
  configure output says the required libraries are present
* How come check_http/check_tcp doesn't work with --ssl?
* How do I compile the Nagios::Plugin perl module?
* I can't compile check_mysql on solaris
* I get '":types" is not exported by the Params::Validate module' when
  running tests
* Why does Solaris use pst3 for check_procs?

Installing
----------

* Some of the root plugins (check_dhcp and check_icmp) haven't been
  installed.  What's happening?
* Why aren't my plugins installed as the nagios user?  And what about
  root plugins?

Development
-----------

* How do I use Git?
* Can I add extra tests to the C routines?
* Can I use the Nagios Plugins in my own project?
* How can I find out more about writing a plugin?
* How do I make changes on nagiosmib?
* How do I prove the C routines work?
* How do I use and update Gnulib?
* How do I use the Nagios::Plugin perl module?
* How do the test parameters in NPTest.pm work?
* Private C APIs

1 files changed, 197 insertions, 0 deletions

diff --git a/web/input/doc/faq/git.md b/web/input/doc/faq/git.md
new file mode 100644
index 0000000..05fd533
--- /dev/null
+++ b/web/input/doc/faq/git.md
@@ -0,0 +1,197 @@
+title: Git
+parent: FAQ
+---
+
+# How do I use Git?
+
+After the 1.4.13 release, the [Nagios Plugins Development Team][team] moved to
+[Git][git] for its code repositories.  This document is a quick introduction
+to Git.
+
+## Differences Between Git and SVN
+
+There is one huge difference between Git and SVN: Git is a distributed SCM
+(Source Code Management system) while SVN is a centralized one.  This doesn’t
+mean we can’t have a central shared Git repository (and we indeed have one),
+this means distributed development can occur around that central repository.
+Another visible difference is that Git have more stages between the working
+directory and the repository.  When you want to add files or changes, you use
+**git add**.  This adds the changes to the repository index, which can be seen
+as a staging area.  When you commit with **git commit**, only the changes in
+the index are considered.  After committing, the changes are still local.  To
+share it with others, you have to push it to a remote repository, or gave
+someone pull from your publicly accessible repository (in most case you will
+still have to push changes there, unless if you were running a git daemon
+straight off your working repository).  Finally you can’t miss the fact that
+there is no more revision numbers, and the distributed nature of Git is the
+reason for that: there is absolutely no way a single number could be tracked
+in a distributed way.  Instead Git uses SHA1 hashes to identify commits (as
+well as other objects in the repository).  Each branch and tag refer to an
+object name (SHA1 hash), and each commits have one or more parents (commit
+objects).  Although SHA1 hashes are 40 digits long, with Git you only have to
+type a handful of digits to reference one.
+
+## Cloning a Project
+
+To work on a project you first have to clone it.  This creates your own local
+repository and until you want to distribute your change or merge changes from
+someone else everything that follows can happen offline.  If you have push
+access, run the command:
+
+    git clone git@github.com:nagios-plugins/nagios-plugins.git
+
+If you just want a local copy or wish to clone it to your workstation, you can
+run this command instead:
+
+    git clone git://github.com/nagios-plugins/nagios-plugins.git
+
+This will create a directory called `nagios-plugins` in your current directory
+with all the `master` code and history (this is roughly equivalent to CVS/SVN
+`HEAD`).  Change directory to `nagios-plugins`.
+
+## Editing Files
+
+You can edit the files in the working area.  To check the status, use:
+
+    git status
+
+This will show a list of changes in the working directory.  Newly made changes
+appear in *red*, while changes added to the index are shown in green.  You can
+use **git diff** to see changes between the current working directory and the
+index (untracked files will not be shown).
+
+## Committing Files
+
+Use **git add** to specify which new files/changes you want to commit; this
+will add the changes to the index.  You can select only partial diffs with
+**git add -p** too.  If you want to commit everything you can use **git commit
+-a** directly.  You can see the changes you are about to commit (difference
+between HEAD and the index) with **git diff --cached**, and then commit them
+with:
+
+    git commit
+
+Add a comment (you have read the [Development Guidelines][guidelines], right?
+:-)).  This commit will be local (affecting only your own repository) so you
+will have to either push your changes, or have someone to pull them from you
+(in the latter case you will most likely still push to a publicly accessible
+clone of your local repository).  If the change is from a contributor, set the
+author at commit time:
+
+    git commit --author="Jane Doe <jane@example.com>"
+
+If you realize that you forgot something in your commit and haven’t pushed it
+yet to a remote repository, you can amend your last commit with **git commit
+--amend**.  You can also amend after a push and force the next update, however
+this will cause non-linear updates and should be done only if the developers
+using your repository are aware of it.
+
+## Reverting Local Modifications
+
+You can revert local modifications with the following steps.  First, if you
+have already staged the changes you will have to unstage them.  As indicated
+in the **git status** message you can do so with the following command:
+
+    git reset HEAD <file>
+
+Then you can revert unstaged changes with:
+
+    git checkout <file>
+
+If you have already committed changes locally and need to undo your commit(s),
+you can use **git reset**.  First find the commit names with **git log** and
+then do either one of these: To keep local modifications (you can commit them
+again, stash them, etc.)
+
+    git reset --soft <commit>
+
+Note that for the purpose of “re-doing” the last commit, **git commit
+--amend** will be much easier than a reset/commit with the same end result.
+To discard local modifications (if you lose important changes with this
+command you may be able to recover them with **git reflog** and **git checkout
+<commit\>**):
+
+    git reset --hard <file>
+
+Do not reset changes that have already been pushed to remote repositories as
+this will cause non-linear updates.  If you do so, developers using those
+repositories should be aware of it.
+
+## Merging Remote Changes
+
+When you work on your local repository you’ll need to keep it up to date with
+the development tree.  This is very similar to **svn update** with the
+difference that it can’t be done if the working tree has any unmerged changes.
+If you do, either commit them or put them aside (Tip: **git stash**).  If you
+cloned from the main Git repository, this command will do a fetch then merge
+any new changes:
+
+    git pull
+
+You can also merge changes from any other fork of the repository.  This
+usually happens if someone ask you to pull from his own repo for some fix or
+enhancements.  Together with **--no-commit** you will have a chance to review
+the changes and make any relevant correction before the merge.  Example:
+
+    git pull --no-commit git://example.com/path/to/repo.git master
+
+## Merging Back to the Main Repository
+
+Once you’re done with your commits and after pulling from the main repository,
+you can push you change back to it.  If you cloned using the *push* url this
+command will push the master branch:
+
+    git push
+
+It you’re trying to push something that would generate merge conflicts, the
+push will be rejected.  You will have yo do a pull first, fix the any
+conflicts locally and then push again.  If your commits are local (you haven’t
+pulled them from someone else or published them somewhere) you can rebase to
+avoid a merge:
+
+    git pull --rebase
+
+Like a merge, this may generate conflicts and let you fix them, but instead of
+creating a merge commit on top of the others, it will undo your commits,
+fast-forward and apply your commits again.  This is cleaner but doesn’t play
+well when it rewrites already published history.
+
+## Going Further
+
+This is a very quick introduction to Git.  There are a lot more useful
+commands for manipulating changes and working with others.  They are all very
+well documented (see **git help [-a]** for a list of commands, **git help
+<cmd\>** or **git <cmd\> --help** shows the man page).  You might also want to
+look into some of the references listed below, or into a book such as [Scott
+Chacon][scott]'s [Pro Git][book].
+
+## References
+
+-  Intro to Distributed Version Control (Illustrated)  
+   <http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/>
+-  A tutorial introduction to Git  
+   <https://www.kernel.org/pub/software/scm/git/docs/gittutorial.html>
+-  Everyday Git With 20 Commands Or So  
+   <http://www.kernel.org/pub/software/scm/git/docs/everyday.html>
+-  Git User’s Manual  
+   <http://www.kernel.org/pub/software/scm/git/docs/user-manual.html>
+-  Git - SVN Crash Course  
+   <http://git.or.cz/course/svn.html>
+-  Git QuickStart  
+   <http://git.or.cz/gitwiki/QuickStart>
+-  Git CheatSheet  
+   <http://git.or.cz/gitwiki/GitCheatSheet>
+-  Understanding Git Conceptually  
+   <http://www.eecs.harvard.edu/~cduan/technical/git/>
+-  The Git Parable  
+   <http://tom.preston-werner.com/2009/05/19/the-git-parable.html>
+-  Git for Computer Scientists  
+   <http://eagain.net/articles/git-for-computer-scientists/>
+
+[team]: team.html "Nagios Plugins Development Team"
+[guidelines]: doc/guidelines.html "Nagios Plugin Development Guidelines"
+[git]: http://git-scm.com/ "Git"
+[scott]: http://scottchacon.com/ "Scott Chacon"
+[book]: http://git-scm.com/book "Pro Git"
+
+<!--% # vim:set filetype=markdown textwidth=78 joinspaces: # %-->