Merge pull request #220 from monopole/noglobbing

Eschew globbing doc

docs/eschewedFeatures.md

@@ -30,10 +30,15 @@ capture improvements from the upstream base.
 ## Environment Variable Substitution
 
 Kustomize wants to support the best practice of storing one's
-configuration in a version control system.
+entire configuration in a version control system.
 
-Dynamically mixing in data from the environment (at `kustomize
+Consulting the environment at `kustomize build` time would
-build` time) would violate that goal.
+violate that goal.
+
+Kustomize will instead provide kustomization file editting
+commands that can accept environment variable arguments, expand
+them at _edit time_, and store the result in the kustomization
+file.
 
 If one wants to, say, set the tag used on an image to match an
 environment variable, the best practice would be to make
@@ -47,6 +52,29 @@ part of some encapsulating work flow executed before `kustomize
 build`.
 
 
+## Globs in Kustomization Files
+
+Kustomize wants to support the best practice of storing one's
+entire configuration in a version control system.
+
+Globbing the local file system for files not explicitly
+declared in the kustomization file at `kustomize build` time
+would violate that goal.
+
+Allowing globbing in a kustomization file would also introduce
+the same problems as allowing globbing in [java import]
+declarations or BUILD/Makefile dependency rules.
+
+Kustomize will instead provide kustomization file editting
+commands that accept globbed arguments, expand them at _edit
+time_ relative to the local file system, and store the resulting
+explicit names into the kustomization file.
+
+In this way the resources, patches and bases used at _build time_
+remain explicitly declared in version control.
+
+
 [base]: glossary.md#base
 [kustomization]: glossary.md#kustomization
 [OTS workflow]: workflows.md#off-the-shelf-configuration
+[java import]: https://www.codebyamir.com/blog/pitfalls-java-import-wildcards