Lib.rs

此crate提供Repository抽象，作为访问git所有功能的中心。

它功能强大，不会牺牲性能，同时与单独使用子crate相比，还能提高便利性。有时它可能会隐藏复杂性，假设性能差异对大多数工具来说并不重要，这包括直接使用底层crate或提交问题。

信任模型

非常简单——根据仓库的所有权与当前进程的用户相比，分配信任。这也
可以被覆盖。此外，git配置文件根据每个部分跟踪其信任级别，基于敏感值，例如可执行文件的路径或某些值将跳过，如果它们来自一个不完全可信的源。

这样，就可以安全地获取数据，而不会冒执行不受信任的可执行文件的风险。

请注意，可以通过设置[open::Options::bail_if_untrusted()]选项来让gix表现得像git或git2。

引入和扩展

使用use git_repository::prelude::*，你应该已经准备好开始了，因为它拉入了各种扩展trait，以便在可能使用它们的对象上提供功能。

方法签名仍然很复杂，可能需要各种参数进行配置和缓存控制。

大多数对现有对象的扩展都提供了一个obj_with_extension.attach(&repo).an_easier_version_of_a_method()，以提供更简单的调用签名。

ThreadSafe 模式

默认情况下，Repository 并不是 Sync，因此不能用于需要 Sync 特性的某些上下文中。

为了解决这个问题，可以使用 [into_sync()][Repository::into_sync()] 将其转换为 ThreadSafeRepository。

对象访问性能

快速访问对象是使用 git 的基本功，仅次于访问引用。因此，了解哪些缓存级别存在以及如何利用它们至关重要。

访问对象时，首先查询的缓存是一个内存限制的 LRU 对象缓存，将它们的 ID 映射到数据和类型。必须在 Repository 中专门启用。如果未命中，则会查找对象，如果命中包，则有一个小型的固定大小的缓存用于 delta-base 对象。

在多次访问相同对象的场景中，对象缓存可能很有用，可以通过 [object_cache_size(…)][crate::Repository::object_cache_size()] 方法来具体配置。

使用 cache-efficiency-debug cargo 功能来了解缓存的实际效率 - 如果缓存在 50% 的时间内未命中，则很容易导致性能下降。

术语

WorkingTree 和 WorkTree

阅读 gix-worktree 程序的官方文档时，给人的印象是工作树和工作树可以互换使用。我们只使用 工作树 这个术语，并尽量保持一致，因为它更短，并且假设它们是相同的。

管道包

为了使使用 子包 和它们的类型更容易，这些包被重新导出到此包的根目录中。以下列出了如何访问嵌套管道包，这些包否则很难发现

git_repository::

• [odb]
  • pack
• protocol
  • transport
    • packetline

libgit2 API 到 gix

以下列出的是一些可能缺失的方法，以及如果有，还提供了解决方案。

以下是一个方法列表，您可能需要它们，以及如果有，还提供了解决方案。

• git2::Repository::open_bare() ➡ ❌ - 使用 [open()] 并丢弃，如果它不是裸的。
• git2::build::CheckoutBuilder::disable_filters() ➡ ❌ (检查期间始终应用过滤器)
• git2::Repository::submodule_status() ➡ [Submodule::state()] - 状态提供更多信息并方便，但实际工作树状态并未执行。

完整性检查

git2 默认通过 strict_hash_verification() 和 strict_object_creation 进行完整性检查，而 gitoxide 目前 尚未实现。

功能标志