[Question]: How to ignore a set of commits?

[nahtnam]

Describe the documentation issue

I have a question surrounding my use case:

1. "template" repo that has a boilerplate next.js app
2. "saas" repo that has a product

There were some issues with my template so I made the changes in both repos and pushed it. For example in the template repo I put const companyName = "template" and in the saas repo I put const companyName = "saas". A day later, I got a PR in the "saas" repo to change the companyName to template, even though I already set it to saas. I want to ignore this change and only sync future changes so I checked out the template_sync_xxxxxxx branch, reverted the commit, and merged the empty PR. However a day later I got the exact same PR. Any way to avoid this?

Links

N/A

Acknowledgements

• [ ] I may be able to submit a pull-request to fix this issue.

[AndreasAugustin]

Hi @nahtnam and thank you for your question.

To ignore changes for a whole file you can use a .templatesyncignore file https://github.com/AndreasAugustin/actions-template-sync#ignore-files

If you want to have some changes ignored: The action uses git and the history. That means you actually need the change commit within your SaaS repository or it will always give you a change PR. The following should work:

• no history revert within the change PR
• make the actual change in the PR and commit a new commit. That way the change commit Id will be within the PR.
• Merge the PR. I think even a squash merge should work in this case.

Not super sure how you reverted the change, but I think that workflow should work.

[nahtnam]

Interesting, I think I was doing that. I was using git revert to create an extra commit, so the original commit was in the history. I did a standard merge (no squash or rebase) but still was facing the problem

I ended up just cloning the repo so that they had the same history and am syncing manually for now

[AndreasAugustin]

Interesting, I think I was doing that. I was using git revert to create an extra commit, so the original commit was in the history. I did a standard merge (no squash or rebase) but still was facing the problem

I ended up just cloning the repo so that they had the same history and am syncing manually for now

Hmmm 🤔 weird. I will think about it. Actually within src/sync_template.sh line 62

git cat-file -e "${TEMPLATE_REMOTE_GIT_HASH}" || COMMIT_NOT_IN_HIST=true
if [ "$COMMIT_NOT_IN_HIST" != true ] ; then
    warn "repository is up to date!"
    exit 0
fi

It is checked if the remote got hash is within the history. It also respects squash commits. @nahtnam not sure why in your case this did not work. Is your code somewhere public? Can you please also add the version of the action you are using?

Will try to rebuild your issue within the next days.