anchor.diff:  * If your `BuildConfig` has a `Git` source type defined, it is dynamically
   disabled, since `Binary` and `Git` are mutually exclusive, and the data in
   the binary stream provided to the builder takes precedence.
  +
  +Instead of a file name, you can pass a URL with HTTP or HTTPS schema to
  +`--from-file` and `--from-archive`. When using  `--from-file` with a URL, the
  +name of the file in the builder image is determined by the `Content-Disposition`
  +header sent by the web server, or the last component of the URL path if the
  +header is not present. No form of authentication is supported and it is not
  +possible to use custom TLS certificate or disable certificate validation.
   
   When using `oc new-build --binary=true`, the command ensures that the
   restrictions associated with binary builds are enforced. The resulting
  
positive.code: stream to the builder. The builder then extracts the contents of the archive
  within the build context directory.
  
  In each of the above cases:
  
  * If your `BuildConfig` already has a `Binary` source type defined, it will
  
negative.code: to `false` (the default setting) in the master configuration file, linking
  secrets to a service is not required.
  ====
  
  [[automatic-addition-of-a-source-secret-to-a-build-configuration]]
  ==== Automatically Adding Source Clone Secrets
  
  {product-title} can automatically add a source clone secret to relevant build
  configurations if the source clone secret includes one or more annotations
  prefixed with `build.openshift.io/source-secret-match-uri-`. The value of each
  annotation indicates a URI pattern of a source repository against which the
  secret matches. The URI pattern must consist of:
  
  - a valid scheme (`*://`, `git://`, `http://`, `https://` or `ssh://`).
  - a host (`\*` or a valid hostname or IP address optionally preceded by `*.`).
  - a path (`/\*` or `/` followed by any characters optionally including `*` characters).
  
  In all of the above, a `*` character is interpreted as a wildcard.
  
  [NOTE]
  ====
  {product-title} will not automatically add a source clone secret to a build
  configuration that already contains a source clone secret.
  ====
  
  If multiple source clone secrets match the URI of a particular source
  repository, {product-title} will select the secret with the longest match. This
  allows for basic overriding, as in the following example.
  
  The following fragment shows two partial source clone secrets, the first
  matching any server in the domain `mycorp.com` accessed by HTTPS, and the second
  overriding access to servers `mydev1.mycorp.com` and `mydev2.mycorp.com`:
  
  [source,yaml]
  ----
  kind: Secret
  apiVersion: v1
  metadata:
    name: matches-all-corporate-servers-https-only
    annotations:
      build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
  data:
    ...
  
  kind: Secret
  apiVersion: v1
  metadata:
    name: override-for-my-dev-servers-https-only
    annotations:
      build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
      build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
  data:
    ...
  ----
  
  Add a `build.openshift.io/source-secret-match-uri-` annotation to a pre-existing
  secret using:
  
  ----
  $ oc annotate secret mysecret \
      'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'
  ----
  
  [[manual-addition-of-a-source-secret-to-a-build-configuration]]
  ==== Manually Adding Source Clone Secrets
  