At the moment, I believe that update will fail if the last validated commit is not in the repository's git history. It's a lot trickier when the top commit is behind the last validated commit, as it is not as easy to verify that the last validated commit is actually valid. Something like this can happen when someone runs the updater. The updater will update last validated commit (content of the last_validated_commit file) automatically. If the user then removes some commits from the repo, the top commit of their local repository will be behind the last validated commit. We could do the following:
check if the top commit of user's local repository is a valid commit by checking if it is contained by the remote repo
check if last_validated_commit is a valid commit by checking if it is contained by the remote repo
check if top commits of target repositories are in sync with the top commit of the auth repo (or if commits defined in auth repo are in their histories)
if that is all true, start the update from the top commit.
if commits of target repositories are all over the place, start the update from the first commit
If last_validated_commit is not contained by the remote repo, that could mean that someone force pushed removed commits (we currently do this if the repository somehow ends up in an invalid state, we do not have a rollback option or revocations - we need to implement them)
when called without --force raise an error
when called with --force, set last validated commit to top commit of the repo, if it is contained by the remote repo and set commits of target repositories to the corresponding commits if none of the target repos are behind the top auth commit. Start update from that commit
if some of these requirements are not met, raise an error even with force. The user might want to clone the repo again at this point, but let them deal with that
At the moment, I believe that update will fail if the last validated commit is not in the repository's git history. It's a lot trickier when the top commit is behind the last validated commit, as it is not as easy to verify that the last validated commit is actually valid. Something like this can happen when someone runs the updater. The updater will update last validated commit (content of the
last_validated_commitfile) automatically. If the user then removes some commits from the repo, the top commit of their local repository will be behind the last validated commit. We could do the following:last_validated_commitis a valid commit by checking if it is contained by the remote repolast_validated_commitis not contained by the remote repo, that could mean that someone force pushed removed commits (we currently do this if the repository somehow ends up in an invalid state, we do not have a rollback option or revocations - we need to implement them)--forceraise an error--force, set last validated commit to top commit of the repo, if it is contained by the remote repo and set commits of target repositories to the corresponding commits if none of the target repos are behind the top auth commit. Start update from that commit