Namespace collisions when caching similarly-named repositories

[0xDEC0DE]

Some idiot replaced the entire caching layer of this thing without first checking if the new one would even work with his existing inputs.

Steps to reproduce

• Attempt to overlay this Giltfile.yaml:

---
repositories:
  - git: [email protected]:bitnami/charts.git
    version: a930cf8b438809fc203f5537898dfa326955dedb
    sources:
    - src: bitnami/fluentd
      dstDir: /tmp/elasticsearch-fluentd/charts/vendor/fluentd
    - src: bitnami/common
      dstDir: /tmp/elasticsearch-fluentd/charts/vendor/common

  - git: [email protected]:elastic/helm-charts.git
    version: c77d1a7ae38c17a553399d397a9fa9f064991803
    sources:
    - src: elasticsearch
      dstDir: /tmp/elasticsearch-fluentd/charts/vendor/elasticsearch
    - src: logstash
      dstDir: /tmp/elasticsearch-fluentd/charts/vendor/logstash

  - git: [email protected]:prometheus-community/helm-charts.git
    version: d5d699cee8b95aa294ea6e691c2a3f9de00b6d79
    sources:
    - src: charts/prometheus-elasticsearch-exporter
      dstDir: /tmp/elasticsearch-fluentd/charts/vendor/prometheus-elasticsearch-exporter

  - git: [email protected]:lebenitza/charts.git
    version: c6597fe0a3ddb11465b38ebe25c19366ef3dfeb6
    sources:
    - src: charts/elasticsearch-curator
      dstDir: /tmp/elasticsearch-fluentd/charts/vendor/elasticsearch-curator

Expected result

The command completes successfully

Actual behavior

11:34AM INF acquiring lock lockfile=/Users/nisimond/.gilt/clone/gilt.lock
11:34AM INF cloning [email protected]:bitnami/charts.git dstDir=/Users/nisimond/.gilt/clone/cache
...
11:34AM INF clone already exists dstDir=/Users/nisimond/.gilt/clone/cache/helm-charts.git
11:34AM INF extracting from=/Users/nisimond/.gilt/clone/cache/helm-charts.git version=d5d699cee8b95aa294ea6e691c2a3f9de00b6d79 to=/Users/nisimond/.gilt/clone/tmp679354367/helm-charts.git
11:34AM ERR error overlaying repositories err="exit status 128"

Miscellany

The test case provides two different flavors of the same problem; in one, there is an old pre-Bitnami fork of the charts.git repo that collides; in the other, there are two entirely separate projects that both have repositories named helm-charts.git.

There is also the case of maintaining a private fork of an active repo, and wishing to maintain caches of both of them concurrently. All of these use cases should be accounted for when resolving this.

[retr0h]

Some idiot replaced the entire caching layer of this thing without first checking if the new one would even work with his existing inputs.

bad @retr0h for merging ....