You really should commit everything first. Especially with repo, it won't sync with uncommitted changes present. Which means also make sure you have created topic branches in each of the affected repositories, so you can more easily find your commits later.
In theory you can use "repo init -b olderbaseline; repo sync" to switch to the older baseline, but this has been reported to not work correctly, due to a bug in the reinit logic.
A work around would be to checkout the manifest back on an older version, e.g.:
(cd .repo/manifests && git checkout --track -b older origin/olderbaseline)
repo sync
But you may also find repo tries to rebase changes from the new baseline on top of the older baseline. "repo sync" is too smart for its own good. It more or less assumes you are only going forward, as a leaf-level contributor, where your changes should be rebased over a newer upstream that you are sync'ing onto. So I'd also probably advise detaching the head everywhere. Which leads me to maybe this will work:
(cd .repo/manifests && git checkout --track -b older origin/olderbaseline)
repo forall -c git checkout HEAD^0
repo sync
No, its not pretty. Jumping back to an older version is not something we had anticipated as a use case when we built repo. Consequently, we somehow made it nearly impossible to do without running afoul of something.
A lot of repo just needs to be scrapped and done over. We know it doesn't work. It works "just barely enough that you can shoot yourself in the foot and still get code on your desktop".