This error appears when trying to unregister or stop background maintenance on a repository that was never registered with the Git maintenance scheduler in the first place.
This error occurs when you attempt to run `git maintenance unregister` or `git maintenance stop` on a repository that is not currently registered for background maintenance tasks. Git's maintenance system tracks which repositories should receive automatic optimization through a global configuration list (maintenance.repo), and this error indicates the current repository is not in that list. The Git maintenance feature, introduced in Git 2.30, allows repositories to be registered for automatic background tasks like garbage collection, commit-graph updates, and prefetching. When registered via `git maintenance start` or `git maintenance register`, the repository is added to your user's global Git config and scheduled tasks are created using your system's scheduler (systemd timers on Linux, launchd on macOS, Task Scheduler on Windows, or cron as a fallback). This error is informational rather than critical - it simply confirms that the repository wasn't set up for automated maintenance. It commonly appears when cleaning up repositories, running unregister commands in scripts without checking registration status first, or when users mistakenly think a repository had background maintenance enabled.
First, verify if the repository is registered for maintenance by checking your global Git configuration:
git config --global --get-all maintenance.repoThis will list all repositories currently registered. If your repository path is not in the output, it's not registered.
You can also check if scheduled tasks are running:
Linux (systemd):
systemctl --user list-timers | grep git-maintenancemacOS (launchd):
launchctl list | grep org.git-scm.gitWindows (Task Scheduler):
schtasks /query | findstr git-maintenanceIf you're running an unregister command in a script or automation and don't care whether the repository was registered, use the --force flag:
git maintenance unregister --forceThis will return success even if the repository is not registered, making it safe for idempotent cleanup scripts.
If you actually want background maintenance enabled for this repository, register it:
git maintenance startThis will:
- Add the repository to maintenance.repo in your global config
- Create scheduled tasks on your system
- Run hourly, daily, and weekly maintenance tasks automatically
Alternatively, use git maintenance register if you want to register without immediately starting the scheduler.
If you've moved or deleted repositories and want to clean up the maintenance.repo list, edit your global config:
git config --global --editLook for lines like:
[maintenance]
repo = /path/to/old/repo1
repo = /path/to/old/repo2Remove entries for repositories that no longer exist or should not be maintained. You can also remove specific entries with:
git config --global --unset-all maintenance.repo /path/to/old/repoPlatform-Specific Scheduler Details:
Git maintenance uses different scheduling systems depending on your platform. On Linux, it prefers systemd user timers (if available) over cron. On macOS, it uses launchd agents via .plist files. On Windows, it uses Task Scheduler via schtasks. The scheduler runs git maintenance run --scheduled hourly, with daily tasks at midnight and weekly tasks at midnight on the first day of the week.
Configuration Side Effects:
When you run git maintenance register, Git automatically sets maintenance.auto = false in the repository's local config. This disables foreground maintenance (like automatic gc during git commands) to prevent conflicts with background maintenance. This setting persists even after unregistering, so you may want to manually re-enable it with git config --unset maintenance.auto if you unregister a repository.
Lock File Behavior:
Each maintenance run takes a lock at .git/maintenance.lock to prevent concurrent executions that could corrupt the repository. If you see lock file errors, another maintenance process may be running, or a stale lock file exists from a crashed process. In Git 2.48+, maintenance provides better hints about these situations.
Conflict with git gc:
Do not run git gc manually on repositories registered for maintenance. The git gc command does not respect the object database lock used by git maintenance, which can lead to race conditions and repository corruption. Use git maintenance run instead for manual maintenance on registered repositories.
No Automatic Cleanup:
There is no automated way to unregister repositories when they're deleted or moved. You should periodically review your maintenance.repo list and clean up stale entries manually to avoid scheduler overhead from attempting maintenance on non-existent repositories.
warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server