-
-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: files deleted in template not being removed in PR #551
Comments
Hi @JessicaS11 and thanks for the bug report. |
Just wanted to add a note that we're going to port in the remainder of the changes manually for the repo linked above ("current behavior") because we need it for an event. But, we can use this one as an ongoing test case (it tracks the same template and is otherwise a scratch repo). |
@JessicaS11 thanks a lot for the sample. |
I too am running into problems with
This suggests |
Hi @WolfGreyDev and thanks for the addon. |
Is there an existing issue for this?
Describe the bug
When a file is deleted in the template repository, the PR opened by the action does not delete the file in the current repo (I'm using "current repo" here to be the repo I'm currently working on that was created from the template and that I'd like to apply the template changes to).
Expected Behavior
I expected any file deleted in the parent repo to also be deleted after the action is run.
Current Behavior
The file removed from the template repo is not removed in the current repo, even with
IS_FORCE_DELETION: true
andGIT_REMOTE_PULL_PARAMS: --allow-unrelated-histories --squash --strategy=recursive -X theirs --no-edit
. This is discussed in an open PR starting here. As noted there, I tried with multiple combinations ofgit_remote_pull_params
to no avail.Steps To Reproduce
To dig in further, I tried imitating what actions-template-sync does locally by adding the original template repo as an upstream to my current repo. I noticed that pulling using the same flags resulted in none of the deleted files being tracked.
Possible Solution
I ultimately tracked down this excellent explanation of how git handles merging with
--allow-unrelated-histories
, which as best as I can tell is likely the issue. One possible solution I found usesgit replace --graft
to create an artificial common history point.UPDATE (I found an error in which hash I used for the graft): This successfully identified the deleted files and a run of
git status
suggests at least all the right files have been touched. I'm not sure if this would be the preferred approach to addressing this bug (I'm already out of my usual depth in git), but if someone can help with designing the best approach I'll take a stab at implementing a solution.Additional Information/Context
No response
Template sync version Version
2.2.3
The text was updated successfully, but these errors were encountered: