What would be an equivalent to a --force-no-copy option to terraform init command

I am using environment branches in my infrastructure git repo where each branch has its own remote state file in S3. When I checkout an environment branch, and rerun terraform init it prompts me if I want to copy state data, to which I always want to answer “no”. I see a --force-copy option that always answers “yes”.

Is there an existing command that always answers “no”? Looking at the docs, it appears --reconfigure might be the option I’m looking for, but I wanted to make sure.

Thanks in advance for any clarification you can provide.

Hi @mojochao,

Indeed, the -reconfigure option essentially means “ignore any previously-initialized backend”. Deleting the .terraform directory and everything in it is a more drastic version of the same idea: it will remove the file where Terraform tracks the currently-initialized backend and all of the cached remote modules and providers, ensuring that you’re starting from a clean state.

You might be interested to know that the Workspaces feature as it exists today was originally designed to be used in conjunction with Git (and other VCS) branches. In practice we’ve learned in the mean time that most users have their needs met better by having a single branch containing a separate root configuration per environment, and so the documentation de-emphasizes workspaces, but if you are happy using Git branches then there is an alternative approach which may work better for you:

  • For each of your environment branches, create a workspace of the same name.
  • When you switch between branches using e.g. git checkout, also switch to the corresponding workspace using terraform workspace select.

Workspaces exist within a single backend, so this avoids the need to reconfigure the backend for each environment but it also requires that you have the same backend configuration in every environment and rely on the workspaces as the per-environment separation mechanism instead.

If you do need a separate backend configuration for each environment (e.g. if you want to use a separate S3 bucket for each) then I’d suggest neither workspaces nor separate branches: instead, I’d recommend having a separate repository (or separate directory within a single repository) for each of your environments, and to switch between them using cd in your shell rather than git checkout. That way each one will have its own separate initialized backend and there is no risk of accidentally migrating states between them.

The section of that docs page When to use Multiple Workspaces describes this alternative multi-configuration approach a little more detail. This is a specific application of the general pattern of module composition.