Create inline conflict markers when copying on a project with already existing files

[DanieleIsoni]

Actual Situation

Now when we do copier copy on an existing project we can decide to override an already existing file or skipping it, but not merging the content of the 2 files

Desired Situation

It would be great if we could merge those two files, maybe putting conflict markers on the whole content of the existing file and the new content from the template.

This would be very useful in files like .gitignore or .tool-versions.

Proposed solution

No response

[pawamoy]

I don't think it's possible to merge two files with zero common history. There's your existing file with its own Git history, and there's the freshly generated file from copier copy. You can easily get a diff from your file to the new file, but I don't see how you could merge the two 🤔 I suppose your project is tracked by Git, so just overwrite and then stage or unstage parts of the diff manually, just like you would manually resolve conflicts.

[DanieleIsoni]

The use case I hade in mind was to generate a project with template-1 and put in its tasks a command to add to the same project the template-2, but those 2 template have files that needs to be merged (e.g.: .gitignore and .tool-versions). But since the tasks are run just after the copy of template-1, it is not yet git tracked.

I thought what could be done is;

<<<<<<<
template-1 whole file content
=======
template-2 whole file content
>>>>>>>

Does it make more sense now?

[pawamoy]

Right, templates that modify the same files is an unsolved problem yet 🙂

Your tasks could definitely git init; git add -A; git commit -m initial before applying the second template. Then nothing prevents the user from deleting the .git folder once they manually "merged" relevant files, to start fresh again.

[PsikoBlock]

~~This feature would be super great to have. cruft and lots of Linux package managers (e.g., Arch Linux or Debian) do a three-way merge where the common ancestor is the previously-applied version of the template.~~

edit: whoops, I think I misunderstood the issue. This seems to be about a fresh copy, not updating. Sorry.

Another approach, which might be error-prone, could be to guess a common ancestor by going through the template history and seeing which version is most similar to the existing file.