* feat(updater): add cooldown option to delay applying updates (#13813)
Introduces a new `zstyle ':omz:update' cooldown <days>` setting that limits
the updater to only apply commits that are at least N days old. Defaults to 0
(current behavior — always pull latest).
When cooldown is set, the updater fetches the remote branch and finds the most
recent commit whose committer timestamp is at least N days old, then applies it
via `git merge --ff-only`. If the local copy is already at or past the cooldown
ref, nothing changes.
- tools/upgrade.sh: reads cooldown zstyle, replaces git pull with fetch +
merge --ff-only when cooldown > 0
- README.md: documents the new setting under "Getting Updates"
- templates/zshrc.zsh-template: adds commented-out cooldown example alongside
frequency, with rephrased comments to clarify how the two work together
* fix(updater): address cooldown review feedback
Pass cooldown into upgrade.sh as -c, extract the update helpers, and only
prompt when a cooldown-eligible commit would actually move HEAD.
* fix(updater): follow first-parent history for cooldown
NOTE: this feature is in alpha / preview mode, it is not guaranteed to work 100% of the
time in all cases. If you experience any issues, open an issue or search for an open
one describing your same situation.
To use this, use the zstyle update mode settings [1] with the value `background-alpha`:
zstyle ':omz:update' mode background-alpha
[1] https://github.com/ohmyzsh/ohmyzsh#getting-updates
The previous check simply compared whether the last commit of the branch
was the same in the local and the remote repository.
This commit also checks whether the remote commit is an ancestor of the
local commit. This fixes the case where the local repository has new
commits after the last published commit.
* Don't error on upgrade no-op
No error code is required for a non failure scenario.
* Manually check whether changes were pulled in `omz update`
Co-authored-by: Marc Cornellà <hello@mcornella.com>
* Suppress the problematic trap output in check_upg
The newly added trap, in systems where `rm` is aliased to `rm="rm -v"`,
shows a message stating that "update.lock" has been removed each time `zsh` is called.
I simply suppressed it with directing the output to `/dev/null`.
* Use `command` instead of >/dev/null to suppress
This early return made it so the lock wasn't removed, therefore locking out
the upgrade script from ever entering the upgrade routine.
Fixes#6138
Note: the logic needs some rework.
`[Oh My Zsh] Would you like to check for updates? [Y/n]: ` does not make sense,
since answering yes will download/apply the new updates instead of checking for them.