Oh My Zsh auto-update behavior with uncommitted core-file changes

Expected state after a conflicted auto-update

If Oh My Zsh's auto-update encounters changes in tracked core files that overlap with upstream commits, `git pull` stops mid-merge. The repository is left with conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) in the affected files under `lib/` or `templates/`, and `.git/MERGE_HEAD` is present. Because the upgrade script runs on every shell startup, the shell remains blocked until you abort the merge or resolve and commit the files manually.

Confirmed facts versus likely explanation

Confirmed: the built-in update runs `git pull` on `~/.oh-my-zsh` without stashing, committing, or snapshotting local changes first. There is no dry-run, preview, or pre-pull backup. Official guidance is to keep customizations in `$ZSH_CUSTOM` and avoid editing core files.

Likely explanation: a fast-forward pull can leave local edits in place even when they are semantically broken by upstream changes. A non-fast-forward pull that touches the same regions produces merge conflicts instead of aborting cleanly.

Steps to recover and prevent recurrence

1. Enter the repository:

cd ~/.oh-my-zsh

2. Abort the in-progress merge:

git merge --abort

3. Restore tracked core files to the last committed state. This discards local edits to `lib/` and `templates/`:

git checkout -- lib templates

4. Confirm the repository is clean:

git status --short

5. Disable automatic updates in `~/.zshrc`:

DISABLE_AUTO_UPDATE=true

Alternatively, set `UPDATE_ZSH_DAYS=-1` to make updates manual-only.

6. Move any customizations into `$ZSH_CUSTOM` rather than editing core files.

Questions with no supported answer

• Backup verification: Oh My Zsh provides no checksum, manifest, or signed-tag mechanism to prove a manually restored backup matches the exact pre-update repository state. Compare file contents against a known-good clone or commit hash if you kept one.
• Abort-on-local-changes: There is no configuration flag to make the auto-update abort when local changes exist. The only reliable controls are disabling auto-update entirely or running `omz update` manually after ensuring the working tree is clean.

If you use `git config --global pull.rebase true`, the update will rebase instead of merge, but it can still leave the repository in a conflicted state; substitute `git rebase --abort` for `git merge --abort` in that case.