Oh My Zsh automatic updates and local core modifications

Question

Oh My Zsh manages framework updates via a git-based mechanism triggered by the ZSH_UPDATE_INTERVAL setting. This process pulls the latest changes from the official repository to ensure the local installation remains current.

A design uncertainty exists when users make direct modifications to files within the core framework directory rather than using custom plugins or the .zshrc file. If a remote update modifies a line that has been locally altered, the automatic update process may encounter a git merge conflict.

Given that these updates often trigger silently in the background upon shell initialization, the behavior for resolving these conflicts remains unclear.

How does the framework handle merge conflicts during an automated update sequence?
  Is there a mechanism to notify the user of a failed automatic update due to local core modifications?

Tasadduq Burney · Answer

Answer
The automatic update mechanism in Oh My Zsh does not attempt a Git merge when you have edited core files. The upgrade_oh_my_zsh script simply pulls the latest changes and overwrites the files in $ZSH, discarding any direct edits you made to core files such as oh-my-zsh.sh or theme/plugin files. Consequently, there is no merge‑conflict resolution step, and the script does not emit a specific notification that the update failed because of local modifications.
Likely explanation
When ZSH_UPDATE_INTERVAL triggers, the upgrade script runs roughly:
cd $ZSH
 git pull --rebase origin master
 # post‑upgrade steps

If the working tree contains uncommitted changes, git pull --rebase will abort and leave the repository in a state where the rebase must be resolved manually. The Oh My Zsh upgrade script does not catch this abort; it proceeds silently, and the local changes are effectively lost because the script later resets the working tree to match the fetched commit (or the user must manually resolve the rebase). In practice, users observe that their edits disappear after an automatic update.
Confirmed facts

The update respects DISABLE_AUTO_UPDATE=true (either as an environment variable or set in ~/.zshrc) to skip the automatic check.
  User‑specific additions placed under $ZSH_CUSTOM are preserved across updates because they are outside the tracked $ZSH directory.
  If you must edit core files, the recommended approach is to fork the Oh My Zsh repository and point $ZSH to your fork, then merge upstream changes manually.

Steps needed for this case

Disable automatic updates if you want to keep your current edits: add export DISABLE_AUTO_UPDATE=true to ~/.zshrc and restart the shell.
  Move any core modifications into a custom plugin or theme under $ZSH_CUSTOM (e.g., $ZSH_CUSTOM/plugins/my‑plugin or $ZSH_CUSTOM/themes/my‑theme.zsh-theme).
  If editing core files is unavoidable, fork the Oh My Zsh repository, set export ZSH=/path/to/your/fork, and periodically run upgrade_oh_my_zsh to merge upstream changes, resolving any conflicts yourself.
  After disabling auto‑updates, manually run upgrade_oh_my_zsh when you want to incorporate upstream fixes, and resolve conflicts with your customizations.

Missing diagnostic detail: Have you already set DISABLE_AUTO_UPDATE or are you using a personal fork of Oh My Zsh? Knowing this will tell you whether step 1 (disabling auto‑updates) is required.

Oh My Zsh automatic updates and local core modifications

1 answer

0 question comments

Answer

Likely explanation

Confirmed facts

Steps needed for this case

Your perspective belongs here.