[Question] Running template-sync multiple times gives the same commits

[ToshY]

Question

I started using template-sync due to mention in dunglas/symfony-docker, but I am very confused on how it works when running multiple times subsequently.

I've created a template based on dunglas/symfony-docker and then run the following command:

$ curl -sSL https://raw.githubusercontent.com/coopTilleuls/template-sync/main/template-sync.sh | sh -s -- https://github.com/dunglas/symfony-docker

commit dab130802efd5bda3fe1053db7c5ee0f2726f15d (origin/main, origin/HEAD, main)
Author: <redacted> <redacted@redacted>
Date:   Tue Aug 19 16:14:34 2025 +0300

    deps: remove unnecessary dependencies


Auto-merging Dockerfile
CONFLICT (modify/delete): docs/alpine.md deleted in HEAD and modified in dab1308 (deps: remove unnecessary dependencies).  Version dab1308 (deps: remove unnecessary dependencies) of docs/alpine.md left in tree.
error: could not apply dab1308... deps: remove unnecessary dependencies
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".

I get the prompt to resolve a conflict and then merge it. That's not a problem. I'll fix the conflict and push it to my own repo.

However, I expect that when I run template-sync again, that now nothing requires syncing anymore, but apparently it will "sync" the same commit again.

$ curl -sSL https://raw.githubusercontent.com/coopTilleuls/template-sync/main/template-sync.sh | sh -s -- https://github.com/dunglas/symfony-docker

commit dab130802efd5bda3fe1053db7c5ee0f2726f15d (origin/main, origin/HEAD, main)
Author: <redacted> <redacted@redacted>
Date:   Tue Aug 19 16:14:34 2025 +0300

    deps: remove unnecessary dependencies


Auto-merging Dockerfile
CONFLICT (modify/delete): docs/alpine.md deleted in HEAD and modified in dab1308 (deps: remove unnecessary dependencies).  Version dab1308 (deps: remove unnecessary dependencies) of docs/alpine.md left in tree.
error: could not apply dab1308... deps: remove unnecessary dependencies
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".

---

As I do not see a mention about this behavior in the docs, I am not sure if it's a bug or that's "intended" behavior.

[mano-lis]

Hi,

Thank you for your issue report.

To answer your question directly: this is the current, expected behavior due to the script's design, but you are right to point out that it's a significant limitation and not an ideal workflow.

Here is how I understand what happens in your use case

First Run: The script analyzes your project and compares it against the template's entire history. It correctly identifies a base commit to sync from. It then tries to apply all the new changes since that commit, which leads to the conflict you saw.

Manual Conflict Resolution: You manually resolve the conflict. At this point, your project contains your own code mixed with the changes from the template.

Second Run: When you run the script again, your manual resolution (where you likely rejected some of the template's changes to keep your own) often makes your project look more similar (i.e., have a smaller diff) to the old base commit than to the new one you were just merging from.

The script is therefore "tricked" by this smaller diff. It re-selects the same old starting point and attempts the exact same update, resulting in the same conflict.

The original goal was to create a simple, single-file script for a one-off update, rather than a full-fledged, stateful synchronization tool. In our opinion, implementing a robust system to handle subsequent runs would significantly increase the script's complexity, taking it beyond that initial, simple scope.

We will leave this issue open in case you or another member of the community has a proposal for an elegant solution to this challenge. Thanks again for your report.

[ToshY]

Hey @mano-lis

I understand the decision to keep it simple, which was also the reason I initially tried it as it is very easy to use.

In the meantime, I will also try out alternatives, like AndreasAugustin/actions-template-sync, to see how they differ regarding usage and complexity (and will report back here for future readers).

Thanks for taking your time to explain.