As pointed out by Philippe: if requested by the user, a special branch (recorded in
TTree::fBranchRef) is created that keeps track of which branch contains objects that
are 'referenced' by TRef. Upon reading and then dereferencing of a TRef object,
TRef::GetObject is called which turns around and calls TBranchRef::Notify which will
call GetEntry on the branch.

There might be a race condition in the multi-threaded TTree::GetEntry if TRef::GetObject
is called during its execution. This is possible if the user inserts schema-evolution
rules that use the TRef. So it might be wise to pre-emptively load the TBranchRef in the
sequential section.

This avoids the deletion of the intermediate files.

Appends the same unique identifier to the name of the partial files
within the same hadd execution.

  by `TTree::Draw`. Three new parameter dre available in `$ROOTSYS/etcsystem.rootrc`

   Hist.Precision.1D:           float
   Hist.Precision.2D:           float
   Hist.Precision.3D:           float

  the fault values are `float`. They can be set to `double`.

the Snapshot method has been added to the TDF interface. This allows
users to write to disk in root format the dataset they read and modified
with the TDataFrame.
This works in single threaded mode only for now.

this has no effect on the interfaces but allows to cleanly return a new
TDataFrame from the TDataFrameInterface.

- Improve diagnostic output of compare() function
- Test inverted matrix times original against identity using
  element by element comparison, and use less strict tolerance
  to account for innacuracies due to matrix inversion

In some circumstances it might be NULL there.

In the input file of the aforementioned tutorial, some top-level branches
depended on another branch that determined their size for every entry
(e.g. the size of an array branch). When processing this kind of data,
branches that depend on size (or count) branches will trigger a call
to TBranch::GetEntry on the latter to ensure their size is read.

The scenario described above made the parallelization of TTree::GetEntry
thread-unsafe, since a count branch could be processed at the same time
by two tasks: its own task and the task that was processing the branch
that needed the size.

This has been solved by factoring out the count branches, which are
processed first sequentially and independently of the rest of the branches.
The latter can be processed safely in parallel afterwards because all the
sizes have been read already.

Currently, we run only a very small subset of checks (the static analysis checks).

For PRs clang-tidy reports only if the regression is triggered by one of the
modified lines.

There is a cron-job mode which is unused and it could be enabled (through travis)
in future. If enabled now, it reports multitude of issues (reports stop at 10K
lines of log due to travis limit).