Update links in README to be relative to current branch

README.md

@@ -7,14 +7,13 @@
 
 
 ## Table of Contents
-1. [Background](../staging/README.md#background)
-1. [Dependencies](../staging/README.md#dependencies)
-1. [Install](../staging/README.md#install)
-1. [Usage](../staging/README.md#usage)
-1. [Tests](../staging/README.md#tests)
-1. [API](../staging/README.md#API)
-1. [Contributing](../staging/README.md#contributing)
-1. [License](../staging/README.md#license)
+1. [Background](#background)
+1. [Dependencies](#dependencies)
+1. [Install](#install)
+1. [Usage](#usage)
+1. [Tests](#tests)
+1. [Contributing](#contributing)
+1. [License](#license)
 
 
 ## Background
@@ -28,7 +27,7 @@ querying an Ethereum node and then persisting core data into a Postgres database
 query for and transform log event and storage data for specifically configured smart contract addresses. Exposing data is a matter of getting
 data from VulcanizeDB's underlying Postgres database and making it accessible.
 
-![VulcanizeDB Overview Diagram](../documentation-updates/documentation/diagrams/vdb-overview.png)
+![VulcanizeDB Overview Diagram](documentation/diagrams/vdb-overview.png)
 
 ## Dependencies
  - Go 1.11+
@@ -39,9 +38,9 @@ data from VulcanizeDB's underlying Postgres database and making it accessible.
 
 
 ## Install
-1. [Building the project](../staging/README.md#building-the-project)
-1. [Setting up the database](../staging/README.md#setting-up-the-database)
-1. [Configuring a synced Ethereum node](../staging/README.md#configuring-a-synced-ethereum-node)
+1. [Building the project](#building-the-project)
+1. [Setting up the database](#setting-up-the-database)
+1. [Configuring a synced Ethereum node](#configuring-a-synced-ethereum-node)
 
 ### Building the project
 Download the codebase to your local `GOPATH` via:
@@ -75,7 +74,8 @@ It can be additionally helpful to add `$GOPATH/bin` to your shell's `$PATH`.
 
     * See below for configuring additional environments
     
-In some cases (such as recent Ubuntu systems), it may be necessary to overcome failures of password authentication from localhost. To allow access on Ubuntu, set localhost connections via hostname, ipv4, and ipv6 from peer/md5 to trust in: /etc/postgresql/<version>/pg_hba.conf
+In some cases (such as recent Ubuntu systems), it may be necessary to overcome failures of password authentication from
+localhost. To allow access on Ubuntu, set localhost connections via hostname, ipv4, and ipv6 from peer/md5 to trust in: /etc/postgresql/<version>/pg_hba.conf
 
 (It should be noted that trusted auth should only be enabled on systems without sensitive data in them: development and local test databases)
 
@@ -111,7 +111,7 @@ As mentioned above, VulcanizeDB's processes can be split into three categories:
 ### Data syncing
 To provide data for transformations, raw Ethereum data must first be synced into VulcanizeDB.
 This is accomplished through the use of the `headerSync`, `sync`, or `coldImport` commands.
-These commands are described in detail [here](../documentation-updates/documentation/sync.md).
+These commands are described in detail [here](documentation/sync.md).
 
 ### Data transformation
 Data transformation uses the raw data that has been synced into Postgres to filter out and apply transformations to
@@ -122,16 +122,16 @@ Custom transformers:
 - Generic Contract Transformer: Generic contract transformation can be done using a built-in command,
 `contractWatcher`, which transforms contract events provided the contract's ABI is available. It also
 provides some state variable coverage by automating polling of public methods, with some restrictions.
-`contractWatcher` is described further [here](../documentation-updates/documentation/generic-transformer.md).
+`contractWatcher` is described further [here](documentation/generic-transformer.md).
 
 - Custom Transformers: In many cases custom transformers will need to be written to provide
 more comprehensive coverage of contract data. In this case we have provided the `compose`, `execute`, and
 `composeAndExecute` commands for running custom transformers from external repositories. Documentation on how to write,
 build and run custom transformers as Go plugins can be found
-[here](../documentation-updates/documentation/custom-transformers.md).
+[here](documentation/custom-transformers.md).
 
 ### Exposing the data
-[Postgraphile](https://www.graphile.org/postgraphile/) is used to expose GraphQL endpoints for our database schemas, this is described in detail [here](../staging/documentation/postgraphile.md).
+[Postgraphile](https://www.graphile.org/postgraphile/) is used to expose GraphQL endpoints for our database schemas, this is described in detail [here](documentation/postgraphile.md).
 
 
 ## Tests
@@ -148,7 +148,7 @@ Contributions are welcome!
 
 VulcanizeDB follows the [Contributor Covenant Code of Conduct](https://www.contributor-covenant.org/version/1/4/code-of-conduct).
 
-For more information on contributing, please see [here](../documentation/contributing.md).
+For more information on contributing, please see [here](documentation/contributing.md).
 
 ## License
-[AGPL-3.0](../staging/LICENSE) © Vulcanize Inc
+[AGPL-3.0](LICENSE) © Vulcanize Inc

documentation/postgraphile.md

@@ -13,7 +13,8 @@ postgraphile --connection postgres://localhost/vulcanize_public --schema=public,
 ```
 
 Arguments:
-- `--connection` specifies the database. The above command connects to the default `vulcanize_public` database defined in [the example config](../staging/environments/public.toml.example).
+- `--connection` specifies the database. The above command connects to the default `vulcanize_public` database 
+defined in [the example config](../environments/public.toml.example).
 - `--schema` defines what schema(s) to expose. The above exposes the `public` schema (for core VulcanizeDB data) as well as a `custom` schema (where `custom` is the name of a schema defined in executed transformers).
 - `--disable-default-mutations` prevents Postgraphile from exposing create, update, and delete operations on your data, which are otherwise enabled by default.
 - `--no-ignore-rbac` ensures that Postgraphile will only expose the tables, columns, fields, and query functions that the user has explicit access to.