I have a git repo cloned and deployed in a server that needs to periodically update from the remote git location in GitHub. For irrelevant operational reasons, we cannot push the updates to the server, we can only poll the remote to check if there are any updates.

We're thinking of tackling this by having an update shell script running on a cronjob that performs a git pull and a few other operations. This script is part of the same git project that is deployed.

My question is, is it safe to have a script perform a git pull from the same repo it lives in? The script itself might evolve and change in the future and it would overwrite itself.

I've done some preliminary testing and it seems that there are no issues, but I want to ask the community to see if there are side effects or problems down the line that we are not accounting for.

CodePudding user response：

"Safe" is kind of a subjective term. Here are some (contrived) reasons not to put the script in the same repo:

1. If someone introduces a bug in the script that prevents itself from updating in the future, it could get stuck and require manually intervention to fix.
2. The script itself might not be able to be renamed or moved without manual intervention. The repo may need to be updated when the script is not running.
3. If a nefarious person gains access to the repo and alters the script in such a way to do something dangerous, the script would be run automatically.

That being said, it's pretty common to run a script from the repo directly. #1 and #2 are not good justifications for running the script outside of the repo. Sure, they take manual intervention to fix the problems, but compare that to having the script outside of the repo to begin with, then you would need manual intervention every time you want to update the script.

Regarding "safe", for security purposes, mainly #3 is relevant, and it's important to note that a nefarious actor could just as easily modify some other aspect of the code regardless of where you run the script from, which arguably would be harder to detect and more devastating.

Weighing these comments, I would say, yes, generally it is probably "safe" to run a script from within the repo.

Tip: if your server doesn't create commits of its own on the branch you are pulling, I'd like to propose an alternative to git pull:

git fetch
git reset --hard @{u}

Note @{u} is branch agnostic and refers to the upstream branch, but you could hard-code it to be origin/main (or whatever your branch name is), if you prefer.

The reason this is slightly better is twofold:

1. In the (hopefully rare!) event that the remote branch is ever force pushed, this script will continue to work as expected. If you use pull it would try to merge in the newly force pushed commits with the previous version of the commits, which certainly would be undesirable.
2. What if your automation does create local commits but it shouldn't have? Then you'd once again get merge commits when you pull.

Another possible alternative, is to change git pull to:

git pull --ff-only

The main difference between doing this and the reset, is the reset will just work every time, even when the above 2 potential problems occur. The pull --ff-only will error on either of the 2 potential problems, rather than possibly silently succeeding and producing something with undesirable results.