Open
Description
I've been digging through the implementation and it looks like the force
flag in pull
only supports two modes:
- Keep all local value and add any new values from SSM (don't force)
- Overwrite all local values with all remote values, implicitly preserving added values (force)
It would be nice to be able to provide more granular concurrency options. For example, consider the following three cases:
- Key1 changed locally but not on SSM
- Key1 changed locally and was changed in SSM
- Key1 only changed on SSM
In git, the pull
behavior is more like:
- Preserves this value
- Identifies the conflict and throws an exception (unless you
prefer-local
orprefer-remote
) - Update this value
It'd be nice to support something similar.
Activity
ambsw-technology commentedon Apr 29, 2019
If it isn't obvious, this request requires a local file that stores the remote values from the last time
pull
orinit
was run. I'd probably create a file like<filename>.orig
right next to<filename>.yml
.ambsw-technology commentedon Apr 29, 2019
As I dig deeper, I think the following case will result in unwanted behavior in the current implementation:
init
with a remote like{'a': {'b': {'c': 'd', 'x': 'y'}}}
/a/b/x
(on SSM)pull
(with or without force)apply
In both cases, the
pull
will treat the locala/b/x
key as "added". The key will be retained and restored to SSM whenapply
is run. Most users will probably want the tool to recognize the remote delete and update the local file accordingly.Diff*
engine #18