I stumbled over this when trying to merge multiple configs.
```
viper.SetConfigName("default")
err := viper.MergeInConfig()
```
which caches file path resolvemenet in `v.configFile`
and then
```
viper.SetConfigName("prod")
err := viper.MergeInConfig()
```
which reuses `v.configFile` without updating it accordingly to the new name.
See c1ccc378a0/viper.go (L1240)
This patch adds the `MergeConfig` and `MergeInConfig` functions to
enable reading new configuration files via a merge strategy rather
than replace. For example, take the following as the base YAML for a
configuration:
hello:
pop: 37890
world:
- us
- uk
- fr
- de
Now imagine we want to read the following, new configuration data:
hello:
pop: 45000
universe:
- mw
- ad
fu: bar
Using the standard `ReadConfig` function the value returned by the
nested key `hello.world` would no longer be present after the second
configuration is read. This is because the `ReadConfig` function and
its relatives replace nested structures entirely.
The new `MergeConfig` function would produce the following config
after the second YAML snippet was merged with the first:
hello:
pop: 45000
world:
- us
- uk
- fr
- de
universe:
- mw
- ad
fu: bar
Examples showing how this works can be found in the two unit tests
named `TestMergeConfig` and `TestMergeConfigNoMerge`.
This patch refactors the IsSet function to examine the keys in order
to see if a key is set instead of simply checking if a value is nil.
This change is necessary due to the fact that default values via
flag bindings will result in the old logic always being true for
the IsSet function due to a type's default value such as 0 for an
integer or an empty string for a string. While a type's default
value may be preferable when getting the value for a key, it
results in a false positive when determining if a key is actually
set. This change enables users to detect whether a key is set by
only returning a flag's value if it has changed.
This reverts commit 8d9577a72e.
The commit is reasonable enough, but this is a major breaking change for Hugo.
We have to figure out how to handle this before we introduce this one.
See https://github.com/spf13/hugo/issues/1129
This fixes the aliases in config files bug. Whenever we register an alias, if there is a value in
the config (or defaults or override) for the alias, we move that value to the new "real key".
Added a test for the bug, which fails without the changes and passes with the changes.
This also fixes a bug in Hugo, where specifying "Taxonomies" in your config file doesn't get recognized,
because Hugo aliases "Taxonomies" to "Indexes" which means that when the code does a Get("Taxnomies") it
got translated to Get("Indexes"), which didn't exist in the original config map.
