有没有办法硬链接(hard link)包含多个 Git 存储库的文件夹中的所有重复对象？

解释:

我在我公司的服务器(Linux 机器)上托管一个 Git 服务器。 这个想法是拥有一个主要的规范存储库，每个用户都没有推送访问权限，但是每个用户都 fork 规范存储库(将规范克隆到用户的主目录，从而实际创建硬链接(hard link))。

/canonical/Repo /Dev1/Repo (objects Hard-linked to /canonical/Repo to when initially cloned) /Dev2/Repo (objects Hard-linked to /canonical/Repo to when initially cloned)

一切正常。问题出现在:

Dev1: Pushes a huge commit onto his fork on server (/Dev1/Repo) Dev2: Fetches that on his local system, makes his own changes and pushes it to his own fork on server (/Dev2/Repo)

(现在相同的“巨大”文件驻留在服务器上的两个开发人员的分支中。它不会自动创建硬链接(hard link)。)

这疯狂地占用了我的服务器空间!

我如何在两个 fork 之间重复的对象之间创建硬链接(hard link)或就此而言是规范的，以便节省服务器空间，并且每个开发人员从他/她的 fork 克隆到他/她的本地机器上时都可以获得所有数据？

最佳答案

Now the same 'huge' file resides in both the developer's forks on the server. It does not create a hard-link automatically

实际上，在 Git 2.20 中，这个问题可能会消失，因为 delta islands，这是一种进行 delta 计算的新方法，这样 一个存在于一个 fork 中的对象就不会变成一个针对未出现在同一个 fork 存储库中的另一个对象的增量。

参见 commit fe0ac2f , commit 108f530 , commit f64ba53 (2018 年 8 月 16 日)Christian Couder (chriscool) .
帮助:Jeff King (peff) , 和 Duy Nguyen (pclouds) .
参见 commit 9eb0986 , commit 16d75fa , commit 28b8a73 , commit c8d521f (2018 年 8 月 16 日)Jeff King (peff) .
帮助:Jeff King (peff) , 和 Duy Nguyen (pclouds) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit f3504ea ，2018 年 9 月 17 日)}

Add delta-islands.{c,h}

Hosting providers that allow users to "fork" existing repositories want those forks to share as much disk space as possible.

Alternates are an existing solution to keep all the objects from all the forks into a unique central repository, but this can have some drawbacks.
Especially when packing the central repository, deltas will be created between objects from different forks.

This can make cloning or fetching a fork much slower and much more CPU intensive as Git might have to compute new deltas for many objects to avoid sending objects from a different fork.

Because the inefficiency primarily arises when an object is deltified against another object that does not exist in the same fork, we partition objects into sets that appear in the same fork, and define "delta islands".
When finding delta base, we do not allow an object outside the same island to be considered as its base.

So "delta islands" is a way to store objects from different forks in the same repository and packfile without having deltas between objects from different forks.

This patch implements the delta islands mechanism in "delta-islands.{c,h}", but does not yet make use of it.

A few new fields are added in 'struct object_entry' in "pack-objects.h" though.

参见 Documentation/git-pack-objects.txt: Delta Island :

DELTA ISLANDS

When possible, pack-objects tries to reuse existing on-disk deltas to avoid having to search for new ones on the fly. This is an important optimization for serving fetches, because it means the server can avoid inflating most objects at all and just send the bytes directly from disk.

This optimization can't work when an object is stored as a delta against a base which the receiver does not have (and which we are not already sending). In that case the server "breaks" the delta and has to find a new one, which has a high CPU cost. Therefore it's important for performance that the set of objects in on-disk delta relationships match what a client would fetch.

In a normal repository, this tends to work automatically.
The objects are mostly reachable from the branches and tags, and that's what clients fetch. Any deltas we find on the server are likely to be between objects the client has or will have.

But in some repository setups, you may have several related but separate groups of ref tips, with clients tending to fetch those groups independently.

For example, imagine that you are hosting several "forks" of a repository in a single shared object store, and letting clients view them as separate repositories through GIT_NAMESPACE or separate repositories using the alternates mechanism.

A naive repack may find that the optimal delta for an object is against a base that is only found in another fork.
But when a client fetches, they will not have the base object, and we'll have to find a new delta on the fly.

A similar situation may exist if you have many refs outside of refs/heads/ and refs/tags/ that point to related objects (e.g., refs/pull or refs/changes used by some hosting providers). By default, clients fetch only heads and tags, and deltas against objects found only in those other groups cannot be sent as-is.

Delta islands solve this problem by allowing you to group your refs into distinct "islands".

Pack-objects computes which objects are reachable from which islands, and refuses to make a delta from an object A against a base which is not present in all of A's islands. This results in slightly larger packs (because we miss some delta opportunities), but guarantees that a fetch of one island will not have to recompute deltas on the fly due to crossing island boundaries.

但是有一个副作用:一些命令更加冗长。 Git 2.23(2019 年第三季度)修复了这个问题。

参见 commit bdbdf42 (2019 年 6 月 20 日)作者 Jeff King (peff) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit a4c8352 ，2019 年 7 月 9 日)}

delta-islands: respect progress flag

The delta island code always prints "Marked %d islands", even if progress has been suppressed with --no-progress or by sending stderr to a non-tty.

Let's pass a progress boolean to load_delta_islands().
We already do the same thing for the progress meter in resolve_tree_islands().

关于linux - 在服务器上删除重复的 Git 分支，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25843553/