Deployed 1cd4d78 to 0.8.0 with MkDocs 1.6.0 and mike 2.1.1

0.8.0/build.md.orig

@@ -0,0 +1,150 @@
+<<<<<<< HEAD
+# Building from Source
+
+## Bazel
+
+To use glog within a project which uses the [Bazel](https://bazel.build/) build
+tool, add the following lines to your `WORKSPACE` file:
+
+``` bazel title="WORKSPACE"
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+http_archive(
+    name = "gflags",
+    sha256 = "34af2f15cf7367513b352bdcd2493ab14ce43692d2dcd9dfc499492966c64dcf",
+    strip_prefix = "gflags-2.2.2",
+    urls = ["https://github.com/gflags/gflags/archive/v2.2.2.tar.gz"],
+)
+
+http_archive(
+    name = "com_github_google_glog",
+    sha256 = "122fb6b712808ef43fbf80f75c52a21c9760683dae470154f02bddfc61135022",
+    strip_prefix = "glog-0.6.0",
+    urls = ["https://github.com/google/glog/archive/v0.6.0.zip"],
+)
+```
+
+You can then add `@com_github_google_glog//:glog` to
+the deps section of a `cc_binary` or
+`cc_library` rule, and `#!cpp #include <glog/logging.h>` to
+include it in your source code.
+
+!!! example "Using glog in a Bazel project"
+    ``` bazel
+    cc_binary(
+        name = "main",
+        srcs = ["main.cc"],
+        deps = ["@com_github_google_glog//:glog"],
+    )
+    ```
+
+## CMake
+
+glog can be compiled using [CMake](http://www.cmake.org) on a wide range of
+platforms. The typical workflow for building glog on a Unix-like system with GNU
+Make as build tool is as follows:
+
+1.  Clone the repository and change into source directory.
+  ``` bash
+  git clone https://github.com/google/glog.git
+  cd glog
+  ```
+2.  Run CMake to configure the build tree.
+  ``` bash
+  cmake -S . -B build -G "Unix Makefiles"
+  ```
+  CMake provides different generators, and by default will pick the most
+  relevant one to your environment. If you need a specific version of Visual
+  Studio, use `#!bash cmake . -G <generator-name>`, and see `#!bash cmake
+  --help` for the available generators. Also see `-T <toolset-name>`, which can
+  be used to request the native x64 toolchain with `-T host=x64`.
+3.  Afterwards, generated files can be used to compile the project.
+  ``` bash
+  cmake --build build
+  ```
+4.  Test the build software (optional).
+  ``` bash
+  cmake --build build --target test
+  ```
+5.  Install the built files (optional).
+  ``` bash
+  cmake --build build --target install
+  ```
+
+Once successfully built, glog can be [integrated into own projects](usage.md).
+||||||| 7b134a5
+=======
+# Building from Source
+
+## Bazel
+
+To use glog within a project which uses the [Bazel](https://bazel.build/) build
+tool, add the following lines to your `WORKSPACE` file:
+
+``` bazel title="WORKSPACE"
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+http_archive(
+    name = "com_github_gflags_gflags",
+    sha256 = "34af2f15cf7367513b352bdcd2493ab14ce43692d2dcd9dfc499492966c64dcf",
+    strip_prefix = "gflags-2.2.2",
+    urls = ["https://github.com/gflags/gflags/archive/v2.2.2.tar.gz"],
+)
+
+http_archive(
+    name = "com_github_google_glog",
+    sha256 = "122fb6b712808ef43fbf80f75c52a21c9760683dae470154f02bddfc61135022",
+    strip_prefix = "glog-0.6.0",
+    urls = ["https://github.com/google/glog/archive/v0.6.0.zip"],
+)
+```
+
+You can then add `@com_github_google_glog//:glog` to
+the deps section of a `cc_binary` or
+`cc_library` rule, and `#!cpp #include <glog/logging.h>` to
+include it in your source code.
+
+!!! example "Using glog in a Bazel project"
+    ``` bazel
+    cc_binary(
+        name = "main",
+        srcs = ["main.cc"],
+        deps = ["@com_github_google_glog//:glog"],
+    )
+    ```
+
+## CMake
+
+glog can be compiled using [CMake](http://www.cmake.org) on a wide range of
+platforms. The typical workflow for building glog on a Unix-like system with GNU
+Make as build tool is as follows:
+
+1.  Clone the repository and change into source directory.
+  ``` bash
+  git clone https://github.com/google/glog.git
+  cd glog
+  ```
+2.  Run CMake to configure the build tree.
+  ``` bash
+  cmake -S . -B build -G "Unix Makefiles"
+  ```
+  CMake provides different generators, and by default will pick the most
+  relevant one to your environment. If you need a specific version of Visual
+  Studio, use `#!bash cmake . -G <generator-name>`, and see `#!bash cmake
+  --help` for the available generators. Also see `-T <toolset-name>`, which can
+  be used to request the native x64 toolchain with `-T host=x64`.
+3.  Afterwards, generated files can be used to compile the project.
+  ``` bash
+  cmake --build build
+  ```
+4.  Test the build software (optional).
+  ``` bash
+  cmake --build build --target test
+  ```
+5.  Install the built files (optional).
+  ``` bash
+  cmake --build build --target install
+  ```
+
+Once successfully built, glog can be [integrated into own projects](usage.md).
+>>>>>>> 0.7.x

0.8.0/contribute.md.orig

@@ -0,0 +1,104 @@
+<<<<<<< HEAD
+# How to Contribute
+
+We'd love to accept your patches and contributions to this project.
+There are a just a few small guidelines you need to follow.
+
+## Contributor License Agreement (CLA)
+
+Contributions to any Google project must be accompanied by a Contributor
+License Agreement. This is not a copyright **assignment**, it simply
+gives Google permission to use and redistribute your contributions as
+part of the project.
+
+-   If you are an individual writing original source code and you're
+    sure you own the intellectual property, then you'll need to sign an
+    [individual
+    CLA](https://developers.google.com/open-source/cla/individual).
+-   If you work for a company that wants to allow you to contribute your
+    work, then you'll need to sign a [corporate
+    CLA](https://developers.google.com/open-source/cla/corporate).
+
+You generally only need to submit a CLA once, so if you've already
+submitted one (even if it was for a different project), you probably
+don't need to do it again.
+
+Once your CLA is submitted (or if you already submitted one for another Google
+project), make a commit adding yourself to the
+[AUTHORS](https://github.com/google/glog/blob/master/AUTHORS) and
+[CONTRIBUTORS](https://github.com/google/glog/blob/master/CONTRIBUTORS) files.
+This commit can be part of your first [pull
+request](https://help.github.com/articles/creating-a-pull-request).
+
+## Submitting a Patch
+
+1.  It's generally best to start by opening a new issue describing the
+    bug or feature you're intending to fix. Even if you think it's
+    relatively minor, it's helpful to know what people are working on.
+    Mention in the initial issue that you are planning to work on that
+    bug or feature so that it can be assigned to you.
+2.  Follow the normal process of
+    [forking](https://help.github.com/articles/fork-a-repo) the project,
+    and setup a new branch to work in. It's important that each group of
+    changes be done in separate branches in order to ensure that a pull
+    request only includes the commits related to that bug or feature.
+3.  Do your best to have [well-formed commit
+    messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
+    for each change. This provides consistency throughout the project,
+    and ensures that commit messages are able to be formatted properly
+    by various git tools.
+4.  Finally, push the commits to your fork and submit a [pull
+    request](https://help.github.com/articles/creating-a-pull-request).
+||||||| 7b134a5
+=======
+# How to Contribute
+
+We'd love to accept your patches and contributions to this project.
+There are a just a few small guidelines you need to follow.
+
+## Contributor License Agreement (CLA)
+
+Contributions to any Google project must be accompanied by a Contributor
+License Agreement. This is not a copyright **assignment**, it simply
+gives Google permission to use and redistribute your contributions as
+part of the project.
+
+-   If you are an individual writing original source code and you're
+    sure you own the intellectual property, then you'll need to sign an
+    [individual
+    CLA](https://developers.google.com/open-source/cla/individual).
+-   If you work for a company that wants to allow you to contribute your
+    work, then you'll need to sign a [corporate
+    CLA](https://developers.google.com/open-source/cla/corporate).
+
+You generally only need to submit a CLA once, so if you've already
+submitted one (even if it was for a different project), you probably
+don't need to do it again.
+
+Once your CLA is submitted (or if you already submitted one for another Google
+project), make a commit adding yourself to the
+[AUTHORS](https://github.com/google/glog/blob/0.7.x/AUTHORS) and
+[CONTRIBUTORS](https://github.com/google/glog/blob/0.7.x/CONTRIBUTORS) files.
+This commit can be part of your first [pull
+request](https://help.github.com/articles/creating-a-pull-request).
+
+## Submitting a Patch
+
+1.  It's generally best to start by opening a new issue describing the
+    bug or feature you're intending to fix. Even if you think it's
+    relatively minor, it's helpful to know what people are working on.
+    Mention in the initial issue that you are planning to work on that
+    bug or feature so that it can be assigned to you.
+2.  Follow the normal process of
+    [forking](https://help.github.com/articles/fork-a-repo) the project,
+    and setup a new branch to work in. It's important that each group of
+    changes be done in separate branches in order to ensure that a pull
+    request only includes the commits related to that bug or feature.
+3.  Do your best to have [well-formed commit
+    messages](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
+    for each change. This provides consistency throughout the project,
+    and ensures that commit messages are able to be formatted properly
+    by various git tools.
+4.  Finally, push the commits to your fork and submit a [pull
+    request](https://help.github.com/articles/creating-a-pull-request).
+>>>>>>> 0.7.x