anchor.diff:  Beyond incremental builds described in <<sec:up_to_date_checks>>, Gradle can save time by reusing outputs from previous executions of a task by matching inputs to the task.
   Task outputs can be reused between builds on one computer or even between builds running on different computers via a build cache.
   
  -For an initial release, we have focused on on the use case where users have an organization wide remote build cache that is populated regularly by continuous integration builds.
  +For an initial release, we have focused on on the use case where users have an organization-wide remote build cache that is populated regularly by continuous integration builds.
   Developers and other continuous integration agents should pull cache entries from the remote build cache.
  -We expect that developers are not allowed to populate the remote build cache and all continuous integration builds are populating the cache while running the `clean` task.
  -
  -For your build to play well with task output caching it is required to work well with the <<sec:up_to_date_checks,incremental build>> feature.
  +We expect that developers will not be allowed to populate the remote build cache, and all continuous integration builds populate the build cache after running the `clean` task.
  +
  +For your build to play well with task output caching it must work well with the <<sec:up_to_date_checks,incremental build>> feature.
   For example, when running your build twice in a row all tasks with outputs should be `UP-TO-DATE`.
   You cannot expect faster builds or correct builds when enabling task output caching when this prerequisite is not met.
   
   NOTE: This feature is a work in progress and is automatically enabled when you enable the build cache, see <<sec:build_cache_enable>>.
   
   [[sec:task_output_caching_example]]
  -=== What does it look like
  -
  -Let us start with a project using the Java plugin which has a few java source files. We run the build the first time.
  +==== What does it look like
  +
  +Let us start with a project using the Java plugin which has a few Java source files. We run the build the first time.
   
   ----
   $> gradle --build-cache compileJava
  
positive.code:     api:org.gradle.testing.jacoco.tasks.JacocoReport[]
  * api:org.gradle.plugin.devel.tasks.ValidateTaskProperties[]
  
  NOTE: It's very important that a cacheable task has a complete picture of its inputs so that the results from one build can be safely re-used somewhere else.
  
  Missing task inputs can cause incorrect cache hits, where different results are treated as identical because the same cache key is used by both executions. Missing task outputs can cause build failures if Gradle does not completely capture all outputs for a given task.
  
  In order to ensure that the inputs and outputs are properly declared use integration tests (for example using TestKit) to check that a task produces the same outputs for identical inputs and captures all output files for the task.
  We suggest adding tests to ensure that the task inputs are relocatable, i.e. that the task can be loaded from the cache into a different build directory (see @api:org.gradle.api.tasks.PathSensitive[]).
  
  [[sec:task_output_caching_known_issues]]
  === Feedback and Known issues
  
  The task output caching feature has known issues that may impact the correctness, usability and performance of your build when using the build cache.
  These issues will be corrected as this feature becomes stable.
  
  Note that task output caching relies on <<sec:up_to_date_checks,incremental build>>.
  Problems which affect incremental build can also affect task output caching even if the affected tasks are not cacheable.
  Most issues can only cause problems if your build cache is populated by non-clean builds or caching has been enabled for unsupported tasks.
  For a current list of open problems with incremental builds see these
  https://github.com/gradle/gradle/issues?utf8=%E2%9C%93&amp;q=is%3Aopen%20label%3Aa%3Abug%20label%3Ain%3Aincremental-build%20[Github issues].
  
  NOTE: When https://github.com/gradle/gradle/issues/new?labels=in:build-cache[reporting issues with the build cache], please check if your issue is a known issue or related to a known issue.
  
  ==== Correctness issues
  
  These issues may affect the correctness of your build when using the build cache. Please consider these issues carefully.
  
  
negative.code: * The content of the build script when it affects execution of the task
  
  Task types need to opt-in to task output caching using the `@api:org.gradle.api.tasks.CacheableTask[]` annotation.
  Note that `@api:org.gradle.api.tasks.CacheableTask[]` is, like `@api:org.gradle.api.tasks.ParallelizableTask[]`, not inherited by subclasses.
  Custom task types are _not_ cacheable by default.
  Currently, the following built-in Gradle tasks are cacheable:
  
  