about summary refs log tree commit diff
path: root/third_party/git/Documentation/technical/repository-version.txt
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/git/Documentation/technical/repository-version.txt')
-rw-r--r--third_party/git/Documentation/technical/repository-version.txt102
1 files changed, 0 insertions, 102 deletions
diff --git a/third_party/git/Documentation/technical/repository-version.txt b/third_party/git/Documentation/technical/repository-version.txt
deleted file mode 100644
index 7844ef30ffde..000000000000
--- a/third_party/git/Documentation/technical/repository-version.txt
+++ /dev/null
@@ -1,102 +0,0 @@
-== Git Repository Format Versions
-
-Every git repository is marked with a numeric version in the
-`core.repositoryformatversion` key of its `config` file. This version
-specifies the rules for operating on the on-disk repository data. An
-implementation of git which does not understand a particular version
-advertised by an on-disk repository MUST NOT operate on that repository;
-doing so risks not only producing wrong results, but actually losing
-data.
-
-Because of this rule, version bumps should be kept to an absolute
-minimum. Instead, we generally prefer these strategies:
-
-  - bumping format version numbers of individual data files (e.g.,
-    index, packfiles, etc). This restricts the incompatibilities only to
-    those files.
-
-  - introducing new data that gracefully degrades when used by older
-    clients (e.g., pack bitmap files are ignored by older clients, which
-    simply do not take advantage of the optimization they provide).
-
-A whole-repository format version bump should only be part of a change
-that cannot be independently versioned. For instance, if one were to
-change the reachability rules for objects, or the rules for locking
-refs, that would require a bump of the repository format version.
-
-Note that this applies only to accessing the repository's disk contents
-directly. An older client which understands only format `0` may still
-connect via `git://` to a repository using format `1`, as long as the
-server process understands format `1`.
-
-The preferred strategy for rolling out a version bump (whether whole
-repository or for a single file) is to teach git to read the new format,
-and allow writing the new format with a config switch or command line
-option (for experimentation or for those who do not care about backwards
-compatibility with older gits). Then after a long period to allow the
-reading capability to become common, we may switch to writing the new
-format by default.
-
-The currently defined format versions are:
-
-=== Version `0`
-
-This is the format defined by the initial version of git, including but
-not limited to the format of the repository directory, the repository
-configuration file, and the object and ref storage. Specifying the
-complete behavior of git is beyond the scope of this document.
-
-=== Version `1`
-
-This format is identical to version `0`, with the following exceptions:
-
-  1. When reading the `core.repositoryformatversion` variable, a git
-     implementation which supports version 1 MUST also read any
-     configuration keys found in the `extensions` section of the
-     configuration file.
-
-  2. If a version-1 repository specifies any `extensions.*` keys that
-     the running git has not implemented, the operation MUST NOT
-     proceed. Similarly, if the value of any known key is not understood
-     by the implementation, the operation MUST NOT proceed.
-
-Note that if no extensions are specified in the config file, then
-`core.repositoryformatversion` SHOULD be set to `0` (setting it to `1`
-provides no benefit, and makes the repository incompatible with older
-implementations of git).
-
-This document will serve as the master list for extensions. Any
-implementation wishing to define a new extension should make a note of
-it here, in order to claim the name.
-
-The defined extensions are:
-
-==== `noop`
-
-This extension does not change git's behavior at all. It is useful only
-for testing format-1 compatibility.
-
-==== `preciousObjects`
-
-When the config key `extensions.preciousObjects` is set to `true`,
-objects in the repository MUST NOT be deleted (e.g., by `git-prune` or
-`git repack -d`).
-
-==== `partialclone`
-
-When the config key `extensions.partialclone` is set, it indicates
-that the repo was created with a partial clone (or later performed
-a partial fetch) and that the remote may have omitted sending
-certain unwanted objects.  Such a remote is called a "promisor remote"
-and it promises that all such omitted objects can be fetched from it
-in the future.
-
-The value of this key is the name of the promisor remote.
-
-==== `worktreeConfig`
-
-If set, by default "git config" reads from both "config" and
-"config.worktree" file from GIT_DIR in that order. In
-multiple working directory mode, "config" file is shared while
-"config.worktree" is per-working directory (i.e., it's in
-GIT_COMMON_DIR/worktrees/<id>/config.worktree)