据我所知，所有分布式版本控制系统都要求您克隆整个存储库。出于这个原因，将大量内容放在一个单一的存储库中是不明智的(感谢 this answer)。我知道这不是错误而是功能，但我想知道这是否是所有分布式修订控制系统的要求。

在分布式 rcs 中，文件(或内容块)的历史记录是一个有向无环图，那么为什么不能克隆这个单个 DAG 而不是存储库中所有图的集合？也许我错过了一些东西，但以下用例很难做到:

最佳答案

从 Git 2.17(2018 年第二季度，10 年后)开始，可以实现 Mercurial 计划实现的功能:“narrow clone ”，即您只检索特定子目录数据的克隆。
这也称为“部分克隆”。
这与现在的不同

git clone --no-checkout --filter=blob:none "file://$(pwd)/srv.bare" pc1 

sha1_file: support lazily fetching missing objects

Teach sha1_file to fetch objects from the remote configured in extensions.partialclone whenever an object is requested but missing.

upload-pack: disable object filtering when disabled by config

When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12, 2017-12-08), it was guarded by the uploadpack.allowFilter config item to allow server operators to control when they start supporting it.

That config item didn't go far enough, though: it controls whether the 'filter' capability is advertised, but if a (custom) client ignores the capability advertisement and passes a filter specification anyway, the server would handle that despite allowFilter being false.

This is particularly significant if a security bug is discovered in this new experimental partial clone code.
Installations without uploadpack.allowFilter ought not to be affected since they don't intend to support partial clone, but they would be swept up into being vulnerable.

fetch: in partial clone, check presence of targets

When fetching an object that is known as a promisor object to the local repository, the connectivity check in quickfetch() in builtin/fetch.c succeeds, causing object transfer to be bypassed.
However, this should not happen if that object is merely promised and not actually present.

Because this happens, when a user invokes "git fetch origin <sha-1>" on the command-line, the <sha-1> object may not actually be fetched even though the command returns an exit code of 0. This is a similar issue (but with a different cause) to the one fixed by a0c9016 ("upload-pack: send refs' objects despite "filter"", 2018-07-09, Git v2.19.0-rc0).

Therefore, update quickfetch() to also directly check for the presence of all objects to be fetched.

(For internal use only.) Prefilter object traversal at promisor boundary.
This is used with partial clone.
This is stronger than --missing=allow-promisor because it limits the traversal, rather than just silencing errors about missing objects.

"git rev-list --exclude-promisor-objects" had to take an object that does not exist locally (and is lazily available) from the command line without barfing, but the code dereferenced NULL.

When a command is invoked with both --exclude-promisor-objects, --objects-edge-aggressive, and a missing object on the command line, the rev_info.cmdline array could get a NULL pointer for the value of an 'item' field.
Prevent dereferencing of a NULL pointer in that situation.

exclude-promisor-objects: declare when option is allowed

The --exclude-promisor-objects option causes some funny behavior in at least two commands: log and blame.
It causes a BUG crash:

$ git log --exclude-promisor-objects
BUG: revision.c:2143: exclude_promisor_objects can only be used
when fetch_if_missing is 0
Aborted
[134]

Fix this such that the option is treated like any other unknown option.
The commands that must support it are limited, so declare in those commands that the flag is supported.
In particular:

pack-objects
prune
rev-list

The commands were found by searching for logic which parses --exclude-promisor-objects outside of revision.c.
Extra logic outside of revision.c is needed because fetch_if_missing must be turned on before revision.c sees the option or it will BUG-crash. The above list is supported by the fact that no other command is introspectively invoked by another command passing --exclude-promisor-object.

diff: batch fetching of missing blobs

When running a command like "git show" or "git diff" in a partial clone, batch all missing blobs to be fetched as one request.

This is similar to c0c578b ("unpack-trees: batch fetching of missing blobs", 2017-12-08, Git v2.17.0-rc0), but for another command.

sha1-file: split OBJECT_INFO_FOR_PREFETCH

The OBJECT_INFO_FOR_PREFETCH bitflag was added to sha1-file.c in 0f4a4fb (sha1-file: support OBJECT_INFO_FOR_PREFETCH, 2019-03-29, Git v2.22.0-rc0) and is used to prevent the fetch_objects() method when enabled.

However, there is a problem with the current use.
The definition of OBJECT_INFO_FOR_PREFETCH is given by adding 32 to OBJECT_INFO_QUICK.
This is clearly stated above the definition (in a comment) that this is so OBJECT_INFO_FOR_PREFETCH implies OBJECT_INFO_QUICK.
The problem is that using "flag & OBJECT_INFO_FOR_PREFETCH" means that OBJECT_INFO_QUICK also implies OBJECT_INFO_FOR_PREFETCH.

Split out the single bit from OBJECT_INFO_FOR_PREFETCH into a new OBJECT_INFO_SKIP_FETCH_OBJECT as the single bit and keep OBJECT_INFO_FOR_PREFETCH as the union of two flags.

index-pack: prefetch missing REF_DELTA bases

When fetching, the client sends "have" commit IDs indicating that the server does not need to send any object referenced by those commits, reducing network I/O.
When the client is a partial clone, the client still sends "have"s in this way, even if it does not have every object referenced by a commit it sent as "have".

If a server omits such an object, it is fine: the client could lazily fetch that object before this fetch, and it can still do so after.

The issue is when the server sends a thin pack containing an object that is a REF_DELTA against such a missing object: index-pack fails to fix the thin pack.
When support for lazily fetching missing objects was added in 8b4c010 ("sha1_file: support lazily fetching missing objects", 2017-12-08, Git v2.17.0-rc0), support in index-pack was turned off in the belief that it accesses the repo only to do hash collision checks.
However, this is not true: it also needs to access the repo to resolve REF_DELTA bases.

Support for lazy fetching should still generally be turned off in index-pack because it is used as part of the lazy fetching process itself (if not, infinite loops may occur), but we do need to fetch the REF_DELTA bases.
(When fetching REF_DELTA bases, it is unlikely that those are REF_DELTA themselves, because we do not send "have" when making such fetches.)

To resolve this, prefetch all missing REF_DELTA bases before attempting to resolve them.
This both ensures that all bases are attempted to be fetched, and ensures that we make only one request per index-pack invocation, and not one request per missing object.

diff: skip GITLINK when lazy fetching missing objs

In 7fbbcb2 ("diff: batch fetching of missing blobs", 2019-04-08, Git v2.22.0-rc0), diff was taught to batch the fetching of missing objects when operating on a partial clone, but was not taught to refrain from fetching GITLINKs.
Teach diff to check if an object is a GITLINK before including it in the set to be fetched.

A remote that can later provide the missing objects is called a promisor remote, as it promises to send the objects when requested.

Initialy Git supported only one promisor remote, the origin remote from which the user cloned and that was configured in the "extensions.partialClone" config option.
Later support for more than one promisor remote has been implemented.

Many promisor remotes can be configured and used.

This allows for example a user to have multiple geographically-close cache servers for fetching missing blobs while continuing to do filtered git-fetch commands from the central server.

Remotes that are considered "promisor" remotes are those specified by the following configuration variables:

• extensions.partialClone = <name>
• remote.<name>.promisor = true
• remote.<name>.partialCloneFilter = ...

Only one promisor remote can be configured using the extensions.partialClone config variable. This promisor remote will be the last one tried when fetching objects.

• combining filters such that only objects accepted by all filters are shown.
  The motivation for this is to allow getting directory listings without also fetching blobs. This can be done by combining blob:none with tree:<depth>.
  There are massive repositories that have larger-than-expected trees - even if you include only a single commit.

A combined filter supports any number of subfilters, and is written in the following form:

combine:<filter 1>+<filter 2>+<filter 3>

• combining of multiple filters by simply repeating the --filter flag.
  Before, the user had to combine them in a single flag somewhat awkwardly (e.g. --filter=combine:FOO+BAR), including URL-encoding the individual filters.

diff: restrict when prefetching occurs

^{Helped-by: Jeff King
Signed-off-by: Jonathan Tan}

Commit 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08, Git v2.22.0-rc0 -- merge listed in batch #7) optimized "diff" by prefetching blobs in a partial clone, but there are some cases wherein blobs do not need to be prefetched.
In these cases, any command that uses the diff machinery will unnecessarily fetch blobs.

diffcore_std() may read blobs when it calls the following functions:

1. diffcore_skip_stat_unmatch() (controlled by the config variable diff.autorefreshindex)
2. diffcore_break() and diffcore_merge_broken() (for break-rewrite detection)
3. diffcore_rename() (for rename detection)
4. diffcore_pickaxe() (for detecting addition/deletion of specified string)

Instead of always prefetching blobs, teach diffcore_skip_stat_unmatch(), diffcore_break(), and diffcore_rename() to prefetch blobs upon the first read of a missing object.
This covers (1), (2), and (3): to cover the rest, teach diffcore_std() to prefetch if the output type is one that includes blob data (and hence blob data will be required later anyway), or if it knows that (4) will be run.

fetch: do not override partial clone filter

^{Signed-off-by: Jonathan Tan}

When a fetch with the --filter argument is made, the configured default filter is set even if one already exists. This change was made in 5e46139376 ("builtin/fetch: remove unique promisor remote limitation", 2019-06-25, Git v2.24.0-rc0 -- merge listed in batch #3) - in particular, changing from:

• If this is the FIRST partial-fetch request, we enable partial
• on this repo and remember the given filter-spec as the default
• for subsequent fetches to this remote.

to:

• If this is a partial-fetch request, we enable partial on
• this repo if not already enabled and remember the given
• filter-spec as the default for subsequent fetches to this
• remote.

(The given filter-spec is "remembered" even if there is already an existing one.)

This is problematic whenever a lazy fetch is made, because lazy fetches are made using "git fetch --filter=blob:none^(man), but this will also happen if the user invokes "git fetch --filter=<filter>^(man)" manually. Therefore, restore the behavior prior to 5e46139376, which writes a filter-spec only if the current fetch request is the first partial-fetch one (for that remote).

关于git - 是否有任何支持部分 checkout /克隆的分布式修订控制系统？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3098029/