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.
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.
This ensures that deps of deps are updated AFTER the dep listing them
is, so that a complicated project with many layers of deps will be
updated correctly. Any new deps encountered along the way are also
cloned, and THEIR deps are also evaluated.
Also added was conflict detection, if a dep has differing versions or
source information, inherited from different places, that will be logged
at the end of update-deps, along with the origin of each conflicting
dep.
The external deps_dir should have higher priority because
it is used by scripts and other build tools to set up the
location of the dependencies. This commit ensures that,
even if a project has set deps_dir in its config file has
lower preference than the command line one.
Add skip_deps=AppListSeparatedByCommas feature.
I agree it's a bit of a weird thing, but it's a reasonable and safe extension. When time comes to properly overhaul stuff, skip_deps should disappear entirely.
Introduce a new 'raw' option for dependency specs in rebar.config file.
For example:
{deps,
{dependency_name, "1.0.*",
{git, "<...>", {branch, "master"}},
[raw]
}
]}.
When this option is specified, rebar does not require the dependency to
have a standard Erlang/OTP layout which assumes presence of either
"src/dependency_name.app.src" or "ebin/dependency_name.app" files.
'raw' dependencies can still contain 'rebar.config' and even can have
the proper OTP directory layout, but they won't be compiled.
Only a subset of rebar commands will be executed on the 'raw'
subdirectories:
get-deps, update-deps, check-deps, list-deps and delete-deps.
This patch modifies rebar_core to allow plugins to participate in the
pre and post processing steps, giving plugin authors more flexibility
and control.
Export two extra environment variables when executing shell commands.
These variables are useful for rebar hooks that rely on Erlang
applications installed as rebar dependencies.
$REBAR_DEPS_DIR contains a fully-qualified name of the directory where
rebar stores dependencies.
$ERL_LIBS is set to $REBAR_DEPS_DIR or to "$REBAR_DEPS_DIR:$ERL_LIBS",
if $ERL_LIBS was defined before.
In git origin/HEAD is a pointer to the default branch. This patch
allows two alternatives to explicitly specifying "HEAD" in git VC specs.
The first is a 2 arity form {git, Url} and the second is {git, Url, ""}
which worked in pre-update-deps rebars.
