Automatic sync v2

[rndquu]

This PR introduced a workflow for syncing https://github.com/ubiquity/ts-template repository template with all of our other repositories.

There are a couple of issues:

1. It doesn't work as expected. Check this PR for example which: a) Clears the main page b) Removes required dependencies
2. For "auto sync" to work we need to keep the sync-template.yml in all of our repositories

"Auto sync" may be useful for small changes like CI updates, ts config edits, etc... Such PRs introduce too many changes which are hard to debug and fix.

What should be done:

1. Remove sync-template.yml from all of our repositories and keep it only in a single place like https://github.com/ubiquity/.github
2. Refactor sync-template.yml to sync only whitelisted files (like deploy.yml or tsconfig.json) with the following strategy:
   • ts-template: file added, target-repo: file missing => propose adding a file
   • ts-template: file modified, target-repo: file exists => propose change
   • ts-template: file deleted, target-repo: file exists => propose delete

P.S. For authentication you may use github PAT of this user https://github.com/ubiquity-devpool

[0x4007]

I think we should give it a chance to figure out how to include the commit in the merge. Once the commit is included I suspect that the same changes won't be pulled next month due to the commit timestamp. This was true in my initial research/testing before funding the idea.

[rndquu]

include the commit in the merge

You mean that sync-template.yml should propose changes only to the files that have been added/updated/removed in the https://github.com/ubiquity/ts-template repo during the last month?

[0x4007]

After the initial run it should only sync new changes. That's the point of this tool.

But we need to merge the commit for git to resolve future pulls in this manner.

[rndquu]

After the initial run it should only sync new changes. That's the point of this tool.

But we need to merge the commit for git to resolve future pulls in this manner.

I still don't understand how it's supposed to work.

Check these index.html pages:

• https://github.com/ubiquity/ts-template/blob/858ab74ead68d8954a8e32074c9b0eb805c5b6ca/static/index.html
• https://github.com/ubiquity/work.ubq.fi/blob/8a8a831fb3222eddabc145ec0b5ac668eb083829/static/index.html

When we open a PR from ts-template to sync the index.html file in the work.ubq.fi the index.html is rewritten with the content from the ts-template which is expected. So I don't fully understand why ts-template should rewrite ones files and don't rewrite others.

[0x4007]

Once the merge commit is included, Git should know not to request the same changes again. Here’s the precise behavior:

1. Git Merge Tracking: When you merge changes from the template repo into the project repo, Git records the merge commit. This means Git is aware of the common history between the two repos, and it won’t attempt to apply the same changes again. As long as the commits from the template repo have already been merged, future merges or pull requests should only contain new changes from the template.
2. Redundant Change Requests: Redundant changes will only happen if: • The merge process resets, ignoring previous merges (e.g., if your cron job force-resets the project repo to an earlier state). • The cron job does not correctly track what has been merged, such as if it creates a pull request without checking the project repo’s current state.

If you merge the pull request created by the cron job and do not reset or rewrite the history in the project repo, Git will not request changes that have already been merged.

In summary:

• As long as the cron job pulls the latest changes and the project repo has the merge commit from the previous pull request, Git will know what has been merged and won’t suggest the same changes again.

I think for initial setup I'll need to merge the pull, and then cherry pick or "revert" the changes on top of that commit.

Once that commit is in, I don't anticipate redundant changes to be requested again. Instead, only new changes to the template will be requested to be merged in, which is precisely the behavior that we want.