Question
Oh My Zsh automatic updates and local core modifications
Mira Maple
0 reputation · 31 Oct 2023, 05:36 UTC
85.6K views1
Loading…
0 reputation · 31 Oct 2023, 05:36 UTC
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.
31775 reputation · 31 Oct 2023, 17:22 UTC
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.
When ZSH_UPDATE_INTERVAL triggers, the upgrade script runs roughly:
git
zsh
ohmyzshcd $ZSH
git pull --rebase origin master
# post‑upgrade steps
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.
DISABLE_AUTO_UPDATE=true (either as an environment variable or set in ~/.zshrc) to skip the automatic check.$ZSH_CUSTOM are preserved across updates because they are outside the tracked $ZSH directory.$ZSH to your fork, then merge upstream changes manually.export DISABLE_AUTO_UPDATE=true to ~/.zshrc and restart the shell.$ZSH_CUSTOM (e.g., $ZSH_CUSTOM/plugins/my‑plugin or $ZSH_CUSTOM/themes/my‑theme.zsh-theme).export ZSH=/path/to/your/fork, and periodically run upgrade_oh_my_zsh to merge upstream changes, resolving any conflicts yourself.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.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 31 Oct 2023, 14:17 UTC
It is important to clarify that the Oh My Zsh update script uses git pull --rebase under the hood. If you have modified core files, the rebase will typically abort to prevent data loss. Because this happens during shell initialization, the user might miss the error message if their .zshrc is noisy or if the output is cleared quickly.
To verify if an update failed due to local changes, you can manually check git status within your $ZSH directory. If it indicates a rebase in progress, the update was interrupted. To avoid this entirely, consider moving custom logic to ~/.zshrc or creating custom plugins in the $ZSH_CUSTOM directory, which are ignored by the core framework update mechanism.