60s still seems to be too low, as it timed out for at least the R15B01
job of the timeout patch merge:
https://travis-ci.org/rebar/rebar/builds/15051701
https://travis-ci.org/rebar/rebar/jobs/15051703

Fix log levels

inttest/rgen1: increase retest timeout (30s -> 60s)

The current default (30s) causes inttest/rgen1 to timeout too often. Add
retest.config to double the timeout.

Make list of commands (for unabbreviation) easier to maintain

It's easier to modify the list with each command on a separate line.
The shell completion scripts have already been modified that way.

Switch retest dep to upstream (dizzyd/retest.git)

Now that Dave has merged all patches, it's safe to switch back to
upstream retest.

rebar_core: fix Dialyzer warning introduced in aa46d85 (#157)

Fix false reporting of (plain) vsn strings

Add missing dep examples and fix existing ones

Fix erl_opts use

Delete unused inttest/retest binary

Avoid getting erl_opts twice in test_compile/3, and make sure the
correctly filtered (platform_define, etc.) version is used.

rebar used to mistakenly report plain version strings like
{vsn, "1.0.0"} as follows:
DEBUG: vcs_vsn: Unknown VCS atom in vsn field: "1.0.0"

Properly detect unknown/unsupported version terms and abort
if we encounter one.

While at it, rename a variable in vcs_vsn/3 to be non-misleading.

As discussed with Martin Schut, remove support for
{app_name, "vsn", {fossil, "url", latest}.

Fixes for #137 and #142

Don't over-aggressively clean the code path in the presence of lib_dir directives

Fix update-deps with certain forms of the {tag, ...} type

Init RUNNER_SCRIPT var in simplenode.runner

RUNNER_SCRIPT variable is not initialized in simplenode.runner and it's
referenced when calling sudo.

Rebar, when it encounters a lib_dir directive, caches the current code
path, adds the libdir(s) and returns the cached copy of the path. When
rebar has finished processing that directory, it restores the cached
path. This is problematic in the below scenario:

        /(lib_dir)->G
  A -> B -> C -> D -> E
   \-> F -> D -> E

When rebar is finished processing B, it restores the code path to what
it was before it processed B, removing C, D, E and G from the code path.
This means when it comes to process F, neither D or E are in the code
path, so any header includes, rebar plugins or parse transforms will not
be in the code path. Without the lib_dir directive, rebar does no code
path cleanups, so everything works fine.

This change makes rebar only remove the explicit lib_dir code paths it
added and adds an inttest that replicates the above scenario.

Sometimes tags like 1.1-3-g3af5478 or d20b53f0 are encountered. The
first is the output of 'git describe', and the second is just a regular
git SHA. git fetch --tags will not pull these down, so do a full git
fetch instead.

* fix Dialyzer warning
* fix formatting

Make update-deps traverse deps breadth-first, top-down

Because rebar_core handles skipping apps, we had to specialcase the
handling in the case of update-deps because it has to do its own dep
handling. The way this was done is not particularly clean, but there
currently does not exist another way for a command to signal rebar_core
that it doesn't want rebar_core to pay attention to skip_apps.

With this change, however, you can update-deps even with local
conflicting changes/commits by simply skipping the deps you don't wish
to update, or whitelisting he ones you do wish to update.

Previously, update-deps on a dep tagged as {branch, ...} would do the
following:

  git fetch
  git checkout -q origin/<branch>

If you were already on that branch, the repo would end up in detached
head state. This is kind of annoying if you're doing local development.

This patch changes the behaviour to be

  git fetch
  git checkout -q <branch>
  git pull --ff-only --no-rebase -q <branch>

The intent of this is to move the branch's HEAD forward to match
upstream without destroying any local commits or changes, and without
accidentally causing merges or rebases. It will fail if the operation
can not be performed without losing history, merging or rebasing.

The previous behaviour has been around a very long time:

064195dc5a (L0R308)

It also exactly mirrors the download_source case, which is not really
true. With git tags and SHAs, one can assume that they don't change, but
branches move all the time.

CONTRIBUTING: apply stylistic change suggested by dizzyd

Always return the errors and warnings from erlydtl

Fix eunit regression introduced in 2716d83a18