Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Add a CLI command/flag to check if conflicts exist #323

Open
CamilleHbp opened this issue Dec 11, 2023 · 0 comments
Open

Comments

@CamilleHbp
Copy link

CamilleHbp commented Dec 11, 2023

Issue

We have no way to know if we are going to overwrite local or remote changes when pushing or pulling from the vault. This is annoying when teammates forget to check for changes before syncing. I am not yet a regular user, I'm beginning to use the project, so I may be wrong. Please correct me if it is so.

Solution

Logic

dotenv-vault pull

  1. Get the last local update date
  2. Get the last remote update date
  3. Throw an error on pull if last_local_update > last_remote_update
    ⇒ this means changes occurred locally between our last pull from the repo and our local edits.

dotenv-vault push

  1. Get the last remote update date
  2. Get the penultimate local update date
  3. Throw an error on push if last_remote_update > penultimate_local_update
    ⇒ this means changes occurred on the remote between our last push to the repo and our local edits.

Modification to the CLI

You could either provide:

  1. A new check-conflicts command. This would display if there is a discrepancy between the remote and the local changes, exit with error if there is, else exit successfully so that we can use it in scripts. This would not break default behaviour.
  2. A new --check-conflicts flag to dotenv-vault push and dotenv-vault pull to exit with an error when pulling/pushing if changes were detected. This would not break default behaviour.
  3. A new --ignore-conflicts flag to dotenv-vault push and dotenv-vault pull to ignore conflicts when pulling/pushing and override local state. This would break default behaviour, the new default would check for conflicts. I think this should be the default anyway, we should ask for input to be sure the user wants to override.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant