mirror of
				https://github.com/zulip/zulip.git
				synced 2025-11-04 05:53:43 +00:00 
			
		
		
		
	The local `/srv/zulip.git` directory has been cloned with `--mirror` since it was first created as a local cache indc4b89fb08. This made some sense at the time, since it was purely a cache of the remote, and not a home to local branches of its own. That changed in3f83b843c2, when we began using `git worktree`, which caused the `deployment-...` branches to begin being stored in `/src/zulip.git`. This caused intermixing of local and remote branches. When02582c6956landed, the addition of `--prune` caused all but the most recent deployment branch to be deleted upon every fetch -- leaving previous deployments with non-existent branches checked out: ``` zulip@example-prod-host:~/deployments/last$ git status On branch deployment-2022-04-15-23-07-55 No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: .browserslistrc new file: .codecov.yml new file: .codespellignore new file: .editorconfig [...snip list of every file in repo...] ``` Switch `/srv/zulip.git` to no longer be a `--mirror` cache of the origin. We reconfigure the remote to drop `remote.origin.mirror`, and delete all refs under `refs/pulls/` and `refs/heads/`, while preserving any checked-out branches. `refs/pulls/`, if the remote is the canonical upstream, contains _tens of thousands_ of refs, so pruning those refs trims off 20% of the repository size. Those savings require a `git gc --prune=now`, otherwise the dangling objects are ejected from the packfiles, which would balloon the repository up to more than three times its previous size. Repacking the repository is reasonable, in general, after removing such a large number of refs -- and the `--prune=now` is safe and will not lose data, as the `--mirror` was good at ensuring that the repository could not be used for any local state. The refname in the upgrade process was previously resolved from the union of local and remote refs, since they were in the same namespace. We instead now only resolve arguments as tags, then origin branches; this means that stale local branches will be skipped. Users who want to deploy from local branches can use `--remote-url=.`. Because the `scripts/lib/upgrade-zulip-from-git` file is "stage 1" and run from the old version's code, this will take two invocations of `upgrade-zulip-from-git` to take effect. Fixes #21901.
This directory contains scripts that:
- 
Generally do not require access to Django or the database (those are "management commands"), and thus are suitable to run operationally.
 - 
Are useful for managing a production deployment of Zulip (many are also used in a Zulip development environment, though development-only scripts live in
tools/). 
For more details, see https://zulip.readthedocs.io/en/latest/overview/directory-structure.html.