Sometimes you may need to revise the history of your of your git repository and force push these changes to your VCS provider (be it GitHub or BitBucket). While sometimes it's required, making force pushes a common part of your workflow can potentially cause issues when running jobs on CircleCI. If you run many jobs on CircleCI, while also changing the repository history often, you will notice jobs may fail due to unknown object references being requested during the checkout phase.
This is because VCS providers handle these types of updates differently and the changes are not always reflected across all services immediately. For instance, the force push can trigger a job but the webhook we receive might be for an old commit hash rather than the new one that was part of the force push. By the time your job runs, it pulls the most recent code and fails because it cannot find the old commit hash in the new repo history.
Also, consider the case for a team that runs many jobs and large workflows. Someone on your team may push a commit that triggers a workflow with many jobs. Some of the jobs in the workflow may not start for hours yet still rely on data from the webhook hours ago. If someone forces a push that changes the repository history it will cause later jobs that run a checkout to have the wrong commit reference than what triggered the original workflow. The becomes especially problematic when you have any jobs queued and someone forces an update.
These issues can be avoided by limiting force pushes as much as possible and making sure jobs/workflows aren't being triggered during these types of push events.