the conflict has disappeared and only the local change is shown form all three-files in the three-way merge

Do you mean that there isn't any conflict marker in the file anymore? If that's the case, I believe we have fixed this in #1813.

About the file hashes:

100644 f163f4b09aad0c495f8f58112ea4aabc9900afe7 1	README.md
100644 f163f4b09aad0c495f8f58112ea4aabc9900afe7 2	README.md
100644 f163f4b09aad0c495f8f58112ea4aabc9900afe7 3	README.md

It's possible that I took a shortcut. I'm not particularly knowledgeable of Git's internals, so I did the easy thing and just updated the index with all three staging modes using the same hash. Should we instead hash three different temporary files, one for each possible conflict resolution?

Seeing that you point at a commit from yesterday as your Copier version, I worry the fix I mention has no effect on your issue 😅 Waiting for your confirmation. However I'm not sure to fully understand your issue yet.

Yeah, rereading it was very unclear. The conflict markers are there in the file, but git mergetool or the vscode merge editor I think use that hashes you see with git ls-files --stage to know what the original files were in the merge. And so with all the hashes the same the conflict disappears (screenshot at the end shows the problem).

I've tried to make a clear reproduction using a test template where only one file (version.txt) changes between versions: https://github.com/borispf/test-template

# In a new directory, copy v1.0 of the template.
git init
copier copy --vcs-ref 1.0 https://github.com/borispf/test-template.git .
git add .
git commit -m v1

# Make a conflicting change.
echo version 2 > version.txt
git add .
git commit -m v2

# Then do a template update to generate the conflict
copier update

Then some relevant output:

# version.txt correctly shown as both modified.
$ git status
On branch main
Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
	both modified:   version.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   .copier-answers.yml

no changes added to commit (use "git add" and/or "git commit -a")

# version.txt has the expected conflict markers.
$ cat version.txt
<<<<<<< before updating
version 2
=======
version 1.1
>>>>>>> after updating

# ls-files shows that version.txt has different versions, but the they all have the same sha1?
$ git ls-files --stage
100644 10f1cf1b6e306695e7572a28faa7077bcadbfcd1 0	.copier-answers.yml
100644 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a 1	version.txt
100644 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a 2	version.txt
100644 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a 3	version.txt

# seems like git thinks all there files are just the v2.
$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
version 2

And now in VSCode's merge editor you can see the issue:

Click on Merge Editor bottom right

All of the changes or merge conflicts are gone.

Similar in vimdiff, all of the source files are the same, at least the result still shows the merge conflict:

This is the repo zipped up if it helps: test.zip.

I hope that's a little clearer.

That's much clearer, thanks.

I never use VSCode's "Merge Editor", only the "Source Control" tab.

Not sure if that's fixable. We could try and set the right hashes for each mode, but that doesn't mean the files would be there for merge tools to see them? My Git-fu is lacking here 🤷

Confirming the issue in a different way: after a copier update, my README.md looks like this:

<<<<<<< before updating
=======
[![documentation](https://img.shields.io/badge/docs-mkdocs-708FCC.svg?style=flat)](https://pawamoy.github.io/pawamoy-testing/)
[![gitter](https://badges.gitter.im/join%20chat.svg)](https://app.gitter.im/#/room/#pawamoy-testing:gitter.im)

Testing this great template

## Installation

This project is available to sponsors only, through my Insiders program.
See Insiders [explanation](https://pawamoy.github.io/pawamoy-testing/insiders/)
and [installation instructions](https://pawamoy.github.io/pawamoy-testing/insiders/installation/).
>>>>>>> after updating

Yet, whether I run git checkout --ours README.md or git checkout --theirs README.md, all I get is an empty file, which corresponds to the contents before the update (the "ours" contents).

Coming back to this:

Should we instead hash three different temporary files, one for each possible conflict resolution?

...and looking at the code, the 3-way merge is done like this:

git(
    "merge-file",
    "-L",
    "before updating",
    "-L",
    "last update",
    "-L",
    "after updating",
    fname,
    Path(old_copy) / fname,
    Path(new_copy) / fname,
    retcode=None,
)

...so we do have files on the disk, and wouldn't need to re-create temporary ones. Maybe I just have to use these files (Path(old_copy) / fname and Path(new_copy) / fname) to get proper hashes, which will help Git actually understand the situation?

EDIT: the hashes are blob ids, not file hashes. Not sure how to retrieve them from Git, if they even exist. Posted this SO question: https://stackoverflow.com/questions/79309642/git-checkout-ours-theirs-after-git-merge-files-with-external-files.

Got a fantastic answer on SO again, sending a PR 🙂