Tracked deletions in git should be synced with the server upon deployment
Currently when using the git deployment feature, if you delete a previously tracked file and push this change to the server it doesn't delete the file from the server.
This means you're left with lots of legacy files that are no longer needed, and your repo is no longer in sync with your server files.
This can cause issues if you ever wanted to push changes back from the server to git as it would then track the previously deleted files and re-add them to the sever!
I'd assume this to be expected behaviour but there might be a reason if anyone wants to shed some light?
The fact that deleted or renamed files are not removed when deploying seems like an obvious flaw in the Cloudways git deployment process and I would assume most people using the feature do not expect it to wok the way it currently does.
Please can we address this! The idea of manually having to go in and remove deleted/renamed files after deploying really makes for a poor experience. in some cases, it could result in legacy/compromised code living on on the server unbeknownst to repository maintainers.
Jason Caldwell commented
+100 for this feature. It shouldn't be difficult to add since Git supports this desired behavior now right out of the box in v2.22. See: `git checkout --no-overlay` https://stackoverflow.com/a/55083251/1219741
In my case it looks there is problem with renaming or moving files. If i rename files of move files to a different folder i think the remove will not get updated properly
Justus Grunow commented
I love Cloudways, but we absolutely need the ability for files deleted in Git to be also removed from the server. I run a flat-file CMS on Cloudways, and manage the entire site via Github. This behavior means that when I delete a page via Git, the page is not deleted from the server. I have to SSH in and manually delete the pages.
Justin Moh commented
Hi, this issue is very easy to be replicated -- might not the same, but close enough.
1. Deploy with your git repository
2. Push a commit
3. Pull the repository on Cloudways
4. `git reset --hard xxxxxxx` (you accidentally pushed credentials) and push the new commit
5. Pull the repository on Cloudways
6. Look in to the file content of that modified file : doomed.
Thanks for looking into my submission.
What you have described is what I'm hoping to do. When I was working on a site recently I found this wasn't the case. I made a support ticket about it to confirm it was expected behaviour and they said it was and that I could make a feature request here.
Maybe it could have been a permissions issue on my end but I'm confused as support said this was intended.