-<h2 id="_using_git_sending_patches">20. Using git / sending patches</h2>\r
-<div class="sectionbody">\r
-<div class="sect2">\r
-<h3 id="_introduction">20.1. Introduction</h3>\r
-<div class="paragraph"><p>For a short introduction into using git, see\r
-<a href="http://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy">http://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy</a>\r
-or, for more documentation, see <a href="http://git-scm.com/documentation">http://git-scm.com/documentation</a></p></div>\r
-<div class="paragraph"><p>Please talk to us before working on new features to see whether they will be\r
-accepted. A good way for this is to open an issue and asking for opinions on it.\r
-Even for accepted features, this can be a good way to refine an idea upfront. However,\r
-we don’t want to see certain features in i3, e.g., switching window focus in an\r
-Alt+Tab like way.</p></div>\r
-<div class="paragraph"><p>When working on bugfixes, please make sure you mention that you are working on\r
-it in the corresponding bug report at <a href="https://github.com/i3/i3/issues">https://github.com/i3/i3/issues</a>. In case\r
-there is no bug report yet, please create one.</p></div>\r
-<div class="paragraph"><p>After you are done, please submit your work for review as a pull request at\r
-<a href="https://github.com/i3/i3">https://github.com/i3/i3</a>.</p></div>\r
-<div class="paragraph"><p>Do not send emails to the mailing list or any author directly, and don’t submit\r
-them in the bugtracker, since all reviews should be done in public at\r
-<a href="https://github.com/i3/i3">https://github.com/i3/i3</a>. In order to make your review go as fast as possible, you\r
-could have a look at previous reviews and see what the common mistakes are.</p></div>\r
-</div>\r
-<div class="sect2">\r
-<h3 id="_which_branch_to_use">20.2. Which branch to use?</h3>\r
-<div class="paragraph"><p>Work on i3 generally happens in two branches: “master” and “next” (the latter\r
-being the default branch, the one that people get when they check out the git\r
-repository).</p></div>\r
-<div class="paragraph"><p>The contents of “master” are always stable. That is, it contains the source code\r
-of the latest release, plus any bugfixes that were applied since that release.</p></div>\r
-<div class="paragraph"><p>New features are only found in the “next” branch. Therefore, if you are working\r
-on a new feature, use the “next” branch. If you are working on a bugfix, use the\r
-“next” branch, too, but make sure your code also works on “master”.</p></div>\r
-</div>\r
-<div class="sect2">\r
-<h3 id="_how_to_build">20.3. How to build?</h3>\r
-<div class="paragraph"><p>You can build i3 like you build any other software package which uses autotools.\r
-Here’s a memory refresher:</p></div>\r
-<div class="literalblock">\r
-<div class="content">\r
-<pre><tt>$ autoreconf -fi\r
-$ mkdir -p build && cd build\r
-$ ../configure\r
-$ make -j8</tt></pre>\r
-</div></div>\r
-<div class="paragraph"><p>(The autoreconf -fi step is unnecessary if you are building from a release tarball,\r
- but shouldn’t hurt either.)</p></div>\r
-<div class="sect3">\r
-<h4 id="_build_system_features">20.3.1. Build system features</h4>\r
-<div class="ulist"><ul>\r
-<li>\r
-<p>\r
-We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate\r
- directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building\r
- in a separate directory is common practice anyway. In case this causes any\r
- trouble when packaging i3 for your distribution, please open an issue.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-“make check” runs the i3 testsuite. See docs/testsuite for details.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-“make distcheck” (runs testsuite on “make dist” result, tiny bit quicker\r
- feedback cycle than waiting for the travis build to catch the issue).\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-“make uninstall” (occasionally requested by users who compile from source)\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-“make” will build manpages/docs by default if the tools are installed.\r
- Conversely, manpages/docs are not tried to be built for users who don’t want\r
- to install all these dependencies to get started hacking on i3.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-non-release builds will enable address sanitizer by default. Use the\r
- --disable-sanitizers configure option to turn off all sanitizers, and see\r
- --help for available sanitizers.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-Support for pre-compiled headers (PCH) has been dropped for now in the\r
- interest of simplicity. If you need support for PCH, please open an issue.\r
-</p>\r
-</li>\r
-<li>\r
-<p>\r
-Coverage reports are now generated using “make check-code-coverage”, which\r
- requires specifying --enable-code-coverage when calling configure.\r
-</p>\r
-</li>\r
-</ul></div>\r
-</div>\r
-</div>\r
-</div>\r
-</div>\r
-<div class="sect1">\r
-<h2 id="_thought_experiments">21. Thought experiments</h2>\r