Remove git merge messages

Author: mpilgrem

doc/faq.md

@@ -6,15 +6,7 @@
 
 ??? question "What is the relationship between Stack and Cabal?"
 
-<<<<<<< HEAD
-The version of GHC, as well as which packages can be installed, are specified by
-the _snapshot_. This may be something like `lts-22.28`, which is from
-[Stackage](https://www.stackage.org/). The
-[user's guide](tutorial/building_your_project.md) discusses the snapshot in more
-detail.
-=======
     'Cabal' can refer to Cabal (the library) or to Cabal (the tool).
->>>>>>> stable
 
     === "Cabal (the library)"
 
@@ -63,302 +55,13 @@ detail.
     The concept of sandboxes is built-in with Stack. All builds are
     automatically isolated into separate package databases.
 
-<<<<<<< HEAD
-~~~yaml
-snapshot: lts-22.28
-packages:
-- .
-extra-deps:
-- text-2.1.1@rev:0
-~~~
-=======
 ??? question "Can I run `cabal` commands inside `stack exec`?"
->>>>>>> stable
 
     Yes. Some `cabal` commands are inconsistent with the `GHC_PACKAGE_PATH`
     environment variable in the Stack environment. Command, for example:
 
-<<<<<<< HEAD
-Add it to the
-[`extra-deps`](configure/yaml/project-specific_configuration.md#extra-deps) list
-in your project's `stack.yaml` file, specifying the package's source code
-location relative to the directory where your `stack.yaml` file lives, e.g.
-
-~~~yaml
-snapshot: lts-22.28
-packages:
-- .
-extra-deps:
-- third-party/proprietary-dep
-- github-version-of/conduit
-- patched/diagrams
-~~~
-
-The above example specifies that the `proprietary-dep` package is found in the
-project's `third-party` directory, that the `conduit` package is found in the
-project's `github-version-of` directory, and that the `diagrams` package is
-found in the project's `patched` directory. This autodetects changes and
-reinstalls the package.
-
-To install packages directly from a Git repository, use e.g.:
-
-~~~yaml
-extra-deps:
-  - git: https://github.com/githubuser/reponame.git
-    commit: somecommitID
-~~~
-
-## What is the meaning of the arguments given to `stack build`, `test`, etc?
-
-Those are the targets of the build, and can have one of three formats:
-
-* A package name (e.g., `my-package`) will mean that the `my-package` package
-  must be built
-* A package identifier (e.g., `my-package-1.2.3`), which includes a specific
-  version. This is useful for passing to `stack install` for getting a specific
-  version from upstream
-* A directory (e.g., `./my-package`) for including a local directory's package,
-  including any packages in subdirectories
-
-## I need to modify an upstream package, how should I do it?
-
-Typically, you will want to get the source for the package and then add it to
-your `packages` list in the `stack.yaml` file. (See the previous question.)
-`stack unpack` is one approach for getting the source. Another would be to add
-the upstream package as a submodule to your project.
-
-## How do I use this with sandboxes?
-
-Explicit sandboxing on the part of the user is not required by Stack. All
-builds are automatically isolated into separate package databases without any
-user interaction. This ensures that you won't accidentally corrupt your
-installed packages with actions taken in other projects.
-
-## Can I run `cabal` commands inside `stack exec`?
-
-With a recent enough version of Cabal (the tool) (1.22 or later), you can. For
-earlier versions this does not work, due to Cabal issue
-[#1800](https://github.com/haskell/cabal/issues/1800). Note that
-even with recent versions, for some commands you may need the following extra
-level of indirection. Command:
-
-~~~text
-stack exec -- cabal exec -- cabal <command>
-~~~
-
-However, virtually all `cabal` commands have an equivalent in Stack, so this
-should not be necessary. In particular, users of Cabal (the tool) may be
-accustomed to the `cabal run` command. With Stack, command:
-
-~~~text
-stack build
-stack exec <program-name>
-~~~
-
-Or, if you want to install the binaries in a shared location, command:
-
-~~~text
-stack install <program-name>
-~~~
-
-assuming your PATH has been set appropriately.
-
-## Using custom preprocessors
-
-If you have a custom preprocessor, for example, Ruby, you may have a file like:
-
-***B.erb***
-
-~~~haskell
-module B where
-
-<% (1..5).each do |i| %>
-test<%= i %> :: Int
-test<%= i %> = <%= i %>
-<% end %>
-~~~
-
-To ensure that Stack picks up changes to this file for rebuilds, add the
-following lines to your `stack.yaml` file:
-
-~~~yaml
-custom-preprocessor-extensions:
-- erb
-
-require-stack-version: ">= 2.6.0"
-~~~
-
-And for backwards compatability with older versions of Stack, also add the
-following line to your Cabal file:
-
-    extra-source-files:   B.erb
-
-You could also use the
-[`--custom-preprocessor-extensions`](configure/yaml/project.md#custom-preprocessor-extensions)
-flag.
-
-## I already have GHC installed, can I still use Stack?
-
-Yes. In its default configuration, Stack will simply ignore any system GHC
-installation and use a sandboxed GHC that it has installed itself. You can find
-these sandboxed GHC installations in the `ghc-*` directories in the
-`stack path --programs` directory.
-
-If you would like Stack to use your system GHC installation, use the
-[`--system-ghc`](configure/yaml/non-project.md#system-ghc) flag or run
-`stack config set system-ghc --global true` to make Stack check your PATH for a
-suitable GHC by default.
-
-Stack can only use a system GHC installation if its version is compatible with
-the configuration of the current project, particularly the snapshot specified by
-the [`snapshot`](configure/yaml/project.md#snapshot) or
-[`resolver`](configure/yaml/project.md#resolver) key.
-
-GHC installation doesn't work for all operating systems, so in some cases you
-will need to use `system-ghc` and install GHC yourself.
-
-## How does Stack determine what GHC to use?
-
-In its default configuration, Stack determines from the current project which
-GHC version, architecture etc it needs. It then looks in the `ghc-<version>`
-subdirectory of the `stack path --programs` directory for a compatible GHC,
-requesting to install one via `stack setup` if none is found.
-
-If you are using the [`--system-ghc`](configure/yaml/non-project.md#system-ghc)
-flag or have configured `system-ghc: true` either in the project `stack.yaml` or
-the global `config.yaml`, Stack will use the first GHC that it finds on your
-PATH, falling back on its sandboxed installations only if the found GHC doesn't
-comply with the various requirements (version, architecture) that your project
-needs.
-
-See issue [#420](https://github.com/commercialhaskell/stack/issues/420) for a
-detailed discussion of Stack's behavior when `system-ghc` is enabled.
-
-## How do I get extra tools used during building?
-
-Stack will automatically install tools used during building required by your
-packages or their dependencies, in particular
-[Alex](https://hackage.haskell.org/package/alex) and
-[Happy](https://hackage.haskell.org/package/happy).
-
-!!! note
-
-    This works when using LTS or nightly snapshots, not with GHC or custom
-    snapshots. You can manually install tools used during building by running,
-    e.g., `stack build alex happy`.
-
-## How does Stack choose which snapshot to use when creating a new configuration file?
-
-It checks the two most recent LTS Haskell major versions and the most recent
-Stackage Nightly for a snapshot that is compatible with all of the version
-bounds in your Cabal file, favoring the most recent LTS. For more information,
-see the snapshot auto-detection section in the architecture document.
-
-## I'd like to use my installed packages in a different directory. How do I tell Stack where to find my packages?
-
-Set the `STACK_YAML` environment variable to point to the `stack.yaml`
-configuration file for your project. Then you can run `stack exec`, `stack ghc`,
-etc., from any directory and still use your packages.
-
-## My tests are failing. What should I do?
-
-Like all other targets, `stack test` runs test suites in parallel by default.
-This can cause problems with test suites that depend on global resources such
-as a database or binding to a fixed port number. A quick hack is to force stack
-to run all test suites in sequence, using `stack test --jobs=1`. For test
-suites to run in parallel developers should ensure that their test suites do
-not depend on global resources (e.g. by asking the operating system for a random
-port to bind to) and where unavoidable, add a lock in order to serialize access
-to shared resources.
-
-## Can I get bash autocompletion?
-
-Yes, see the [shell-autocompletion](shell_autocompletion.md) documentation.
-
-## How do I update my package index?
-
-Users of Cabal (the tool) are used to running `cabal update` regularly. You can
-do the same with Stack by running `stack update`. But generally, it's not
-necessary: if the package index is missing, or if a snapshot refers to
-package/version that isn't available, Stack will automatically update and then
-try again. If you run into a situation where Stack doesn't automatically do the
-update for you, please report it as a bug.
-
-## Isn't it dangerous to automatically update the index? Can't that corrupt build plans?
-
-No, Stack is very explicit about which packages it's going to build for you.
-There are three sources of information to tell it which packages to install:
-the selected snapshot, the `extra-deps` configuration value, and your local
-packages. The only way to get Stack to change its build plan is to modify one
-of those three. Updating the index will have no impact on Stack's behavior.
-
-## I have a custom package index I'd like to use, how do I do so?
-
-You can configure this in your project-level configuration file (`stack.yaml`,
-by default). See [YAML configuration](configure/yaml/yaml_configuration.md).
-
-## How can I make sure my project builds against multiple GHC versions?
-
-You can create multiple YAML configuration files for your project, one for each
-build plan. For example, you might set up your project directory like so:
-
-~~~text
-myproject/
-  stack-ghc-9.0.2.yaml
-  stack-ghc-9.2.4.yaml
-  stack.yaml --> symlink to stack-ghc-9.2.4.yaml
-  myproject.cabal
-  src/
-    ...
-~~~
-
-When you run `stack build`, you can set the `STACK_YAML` environment variable to
-indicate which build plan to use. On Unix-like operating systems command:
-
-~~~bash
-stack build  # builds using the default stack.yaml
-STACK_YAML=stack-ghc-7.10.yaml
-stack build  # builds using the given yaml file
-~~~
-
-On Windows (with PowerShell) command:
-
-~~~ps
-$Env:STACK_YAML='stack-ghc-9.0.2.yaml'
-stack build
-~~~
-
-## I heard you can use this with Docker?
-
-Yes, Stack supports using Docker with images that contain preinstalled Stackage
-packages and the tools. See [Docker integration](topics/docker_integration.md)
-for details.
-
-## How do I build a statically-linked executable on Linux?
-
-The way that Stack itself builds statically-linked Stack executables for Linux
-is as follows:
-
-* In the Cabal file, the following
-  [`ld-options`](https://cabal.readthedocs.io/en/stable/cabal-package.html#pkg-field-ld-options)
-  are set: `-static` and `-pthread`.
-
-* The Stack command is run in a Docker container based on Alpine Linux. The
-  relevant Docker image repository is set out in Stack's `stack.yaml` file. See
-  also Olivier Benz's [GHC musl project](https://gitlab.com/benz0li/ghc-musl).
-
-* Stack's configuration includes:
-
-    ~~~yaml
-    extra-include-dirs:
-    - /usr/include
-    extra-lib-dirs:
-    - /lib
-    - /usr/lib
-=======
     ~~~text
     stack exec --no-ghc-package-path -- cabal build
->>>>>>> stable
     ~~~
 
 ## GHC or GHCi-related