* **I'm not technical enough to set up Giterary, but I like some of the features, and the price is right. What can I do?**

TODO: There's a lot going on, I know.

If you're installing on Linux, the *install.sh* script will take you through collecting your various bits of configuration information, setting up your directory structures, permissions, usernames, passwords, and other fun things. See the [[INSTALL|INSTALL documentation]] referencing the *install.sh* script for more information.

* **Markdown is *okay*, but I like X better. Do you support that?**

Probably? Is it text-based? Is it easy to edit from an HTML textarea tag? Well, there are certainly places to add such things, but there isn't anything particularly fancy. For the programmers out there, it's a PHP switch statement, that passes off handling to a function that is assumed to return valid HTML. However, a lot of work goes into making Markdown-specific editing possible (with the addition of annotations, the live Markdown preview, etc.)

* **Editing with textareas is pretty lame. Why don't you use ckeditor? Or something more modern, or Javascript-y, or HTML5 friendly?**

In the same way that text files are hard to screw up, so too are textareas. Every browser can render them, every person can use them. Not to disparage the writers of editors like ckeditor, or the users of Giterary, but sometimes it's nice to have something familiar, even if it is sort of lame.

There's also that, in the event of complete Javascript failure (or you run NoScript), your browser should be able to render the textarea just fine, and **also** be able to preview and commit your changes without need for the client-side Javascript. I'm a fan of elegantly degrading web applications.

That said, you have options:

* Greasemonkey scripts let you do all sorts of interesting things to web sites. You could apply something like a [Vim emulator][vim-in-textarea] on top of the editing window, or any strange, awesome thing you can think of to make the textarea more useful to you.

* Browser plugins like provide similar modified editing and browsing experiences.

* Or even better, clone your Giterary repository locally, edit using your favorite text editors, and synchronize whenever you see fit. Some of my favorite text editors:

* [Vim][vim] (or [Emacs][emacs], if you're into that sort of thing)

* [Notepad++][notepadpp]

* [TextMate][textmate]

* [SublimeText][sublimetext] (haven't used it personally, but the things I hear is that I should).

[vim-in-textarea]: https://github.com/jakub-m/vim-in-textarea

[vim]: http://www.vim.org/

[emacs]: http://www.gnu.org/software/emacs/

[notepadpp]: http://notepad-plus-plus.org/

[textmate]: http://macromates.com

[sublimetext]: http://www.sublimetext.com/

* **I don't understand why I would ever use partitioning. Why would I ever want to split up my document?**

Valid question. It's more of a feature for people who, prior to writing in Giterary, or prior to sane document management practices, worked only in single, monolithic documents (see: one great big Word document, or something like that). A feature like that is useful because it lets you split up a larger work into smaller, more manageable chunks.

* **Something broke, and my repository is messed up. Giterary isn't helping at all. I don't want to start over. Please help.**

More often than not, an external git client, graphical or otherwise, will be able to answer your git repository's quandary better. At very worst, copying your working directory out, and cloning from your last known good repository state should be sufficient to not lose what is in your working directory.

* **I put something in my repository that is, um, "sensitive." As in, it needs to be gone. Really gone.**

It happens sometimes. Usually, performing a "hard reset" to a commit before the sensitive information was in the system is sufficient.

git reset --HARD COMMIT_BEFORE_BAD_STUFF_HAPPENED

But sometimes there are things you want to keep that happened *after* the sensitive information got into the system. In that case, you have to use git to "rewrite history." For this, Github [has a decent article on how to do just this](https://help.github.com/articles/remove-sensitive-data).

* **Is Giterary supported on X (X being my operating system or computing platform of choice)?**

PHP, being an interpreted language, does not require compilation, and therefore, is supported on any platform a PHP interpreter is available (version 5.3). However, you also need git to be able to run git, and a web server capable of serving PHP scripts, and your operating system needs to support the type of piping used by the [*proc_open*][proc_open] function in PHP. But other than that, pretty platform agnostic, I'd think.

[proc_open]: http://php.net/manual/en/function.proc-open.php

* **I have a healthy degree of paranoia, does Giterary support file encryption?**

Not at the moment, but it's an interesting and precarious feature. For instance: you could implement it such that you would have to enter an extra password in order to "unlock" a file for editing. However, unless said paranoid individual isn't *also* paranoid about their network traffic, it's possible that the submission of that password could be intercepted.

So: it's possible. An extra extension handler, plus perhaps a modified form element, and you'd be in business. But it certainly wouldn't be perfect, and would play hell with Giterary's diff mechanisms.

* **What coding conventions were used in the application, if any, you talentless hack?**

You can read about some of the [[CONVENTIONS|programming conventions]], if you really want, but it's mostly the technical grandstanding and pseudo-philosophical ravings of a madman.

* **What license is Giterary released under?**

Giterary is licensed under the GNU Public License, version 3. License text is (should be) included in your distribution of Giterary.

* **There already exist industry standard word processing and novel writing tools, cheaply available, reliable, and better documented than this. Giterary is destined to fail.**

TODO: Wow. No punches pulled.

* **Does Giterary support X method of authentication? Y method of authorization? How can I give person A permissions to do this, but not person B?**

TODO: There is only so much I can do to predict what people will use Giterary for, or who the will want to be able to use Giterary.