Merge conflicts while running copier update

[farhaan-shamsee]

My scenario:
The user use copier update command and selects/unselect the sample applications that needs to be enabled/disabled from a question.

The question is like below:

sample_apps:
  help: Please select sample app you would like to enable.
  default: []
  type: str
  multiselect: true
  choices:
    "sample-app1" : "sample-app1"
    "sample-app2" : "sample-app2"
    "sample-app3" : "sample-app3"
    "sample-app4" : "sample-app4"
  when: "[2[ enable_sample_apps ]2]"

now based on above selection I am updating a kustomization.yaml file, like below

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  [2%- if enable_sample_apps %2]
  [2%- if "sample-app1" in sample_apps %2]
  - sample-app1.yaml
  [2%- endif %2]
  [2%- if "sample-app2" in sample_apps %2]
  - sample-app2.yaml
  [2%- endif %2]  #and so on for other sample apps
  [2%- else %2]
  []
  [2%- endif %2]

now this works as expected.
But the conflict arise when the user has updated the kustomization.yaml manually by adding a file name (in this case my-app.yaml) to his own manifest. And when the next time user runs copier update(and lets assume he chose to enable sample-app3) he gets merge conflict like below:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
<<<<<<< before updating
  - my-app.yaml
  - sample-app1.yaml
  - sample-app2.yaml
=======
  - sample-app3.yaml
>>>>>>> after updating

I want to know is this the expected behavior? Or maybe the is a better way to handle this.
I want to automate these, and find a way to not have the conflicts at all rather than using tasks or --conflict rej way.

Currently a workaround which I can think of for this is to ask a separate question from user, if they want to add their own sample apps also and then create an entry for a new folder in the kustomization.yaml and ask user to put their sample apps in that particular folder.

[sisp]

I'm afraid the merge conflict cannot be avoided to the best of my knowledge because of the way Git's patching algorithm works, which Copier relies on internally.

Let's see what's happening in your example.

The change between generating a project with the first set of answers and the second set of answers without manual user changes is this:

 apiVersion: kustomize.config.k8s.io/v1beta1
 kind: Kustomization
 resources:
   - sample-app1.yaml
   - sample-app2.yaml
+  - sample-app3.yaml

The user's change after generating the project with the first set of answers is this:

 apiVersion: kustomize.config.k8s.io/v1beta1
 kind: Kustomization
 resources:
+  - my-app.yaml
   - sample-app1.yaml
   - sample-app2.yaml

Copier internally performs a 3-way merge to combine the changes in the template and by the user. Git internally computes diffs and uses them to patch the project. Each patch contains hunks (changes and their context). When the context of a change does not match, then a merge conflict occurs. In this case, the change introduced by the new version of the template conflicts with the context of the hunk containing the user's change in the project. Reducing the number of context lines might help, but there's a risk of applying a patch hunk in the wrong place.

Thus, I'm afraid I currently don't see a way to avoid the merge conflict as is.

[pawamoy]

But the user could always run Git commands after the update, to automatically accept both changes everywhere 🤷