git push对于大量仓库来说非常慢 [英] git push is very slow for a huge repo

问题描述

我遇到的问题与 git push非常相似分支慢了 但是那里的答案不适合我的情况.

I am having the same issue as in - git push is very slow for a branch but the answer there doesn't fit my situation.

我正在与一个拥有大量仓库的公司GitHub进行合作.我的过程如下:

I am working against a corporate GitHub with a very large repo. My process is as follows:

1)从主人那里拉起

2)创建新分支

3)提交

4)推送分支以创建拉取请求.

4) Push the branch to create a pull request.

当在(4)上推动分支时，它要写入1,000,000个对象，而当我所做的提交仅更改1行时，这大约需要3gb.

When pushing the branch on (4) it wants to write over 1,000,000 objects which take about 3gb when the commit I made was to change only 1 line.

如果我转到GitHub UI，并从UI创建与(2)中名称相同的分支，然后推入该分支，则推入所需的时间不到一秒钟.不用说master和我的分支之间的更改很小(没有添加或删除大文件).

If I go to the GitHub UI and create a branch with the same name as in (2) from the UI, then push into that branch, the push takes less than a second. Needless to say that the changes between master and my branch are very minor (no big file added or deleted).

我该怎么做才能使Git仅推送相关数据，而不推送整个仓库?

在Windows版本2.17.0上的Git

Git on Windows ver 2.17.0

推荐答案

您可以尝试通过以下方式进行相同的推送:

You could try your same push with:

• 适用于Windows 2.21的Git
• git config --global pack.sparse true(我在2019年3月在这里提出了 pack.sparse选项)

• Git For Windows 2.21
• git config --global pack.sparse true (I presented the pack.sparse option here in March 2019)

此选项来自这些补丁，并在提交d5d2e93 ，其中包括以下注释:

This option is from those paches, and implemented in commit d5d2e93, which includes the comment:

这些改进将使超级 大型Windows存储库.

These improvements will have even larger benefits in the super- large Windows repository.

在您的情况下，这应该很有趣.

That should be interesting in your case.

请参阅" 探索新领域 "中的 德里克·斯托利

See "Exploring new frontiers for Git push performance" from Derrick Stolee

git push通常会显示以下内容:

A git push would typically display something like:

$ git push origin topic
Enumerating objects: 3670, done.
Counting objects: 100% (2369/2369), done.
Delta compression using up to 8 threads
Compressing objects: 100% (546/546), done.
Writing objects: 100% (1378/1378), 468.06 KiB | 7.67 MiB/s, done.
Total 1378 (delta 1109), reused 1096 (delta 832)
remote: Resolving deltas: 100% (1109/1109), completed with 312 local objects.
To https://server.info/fake.git
* [new branch] topic -> topic

枚举"是指:

Git构造一个打包文件，其中包含您要尝试推送的提交以及服务器需要了解该提交的所有提交，树和Blob(统称为对象).
它会找到一组提交，树和Blob，以便每个可访问对象都位于该集中或已知在服务器上.

Git constructs a pack-file that contains the commit you are trying to push, as well as all commits, trees, and blobs (collectively, objects) that the server will need to understand that commit.
It finds a set of commits, trees, and blobs such that every reachable object is either in the set or known to be on the server.

目标是找到正确的边界"

The goal is to find the right "frontier"

作为有趣提交的直接父项的无趣提交形成了边界

The uninteresting commits that are direct parents of interesting commits form the frontier

要确定哪些树和斑点有趣，旧算法首先确定所有不感兴趣的树和斑点.

To determine which trees and blobs are interesting, the old algorithm first determined all uninteresting trees and blobs.

从边界中的每一个无趣的提交开始，递归地从其根树开始走，并将所有可到达的树和斑点标记为无趣.此步会跳过那些已经标记为不感兴趣的树，以避免再次访问该图的较大部分.

Starting at every uninteresting commit in the frontier, recursively walk from its root tree and mark all reachable trees and blobs as uninteresting. This walk skips trees that were already marked as uninteresting to avoid revisiting potentially large portions of the graph.

新

旧算法是递归的:它采用一棵树并在所有子树上运行该算法.

New

The old algorithm is recursive: it takes a tree and runs the algorithm on all subtrees.

新算法使用路径来减少树遍历的范围.它也是递归的，但是它需要一组树.
在开始算法时，树的集合包含了无趣的和有趣的提交的根树.

The new algorithm uses the paths to reduce the scope of the tree walk. It is also recursive, but it takes a set of trees.
As we start the algorithm, the set of trees contains the root trees for the uninteresting and the interesting commits.

新的树木步行以递归方式探索包含有趣和无趣的树木的路径.
在B的树内，我们有名为F和G的子树.
这两个集合都有有趣和无趣的路径，因此我们递归到每个集合中.这会继续进入B/F和B/G. B/F集合不会递归到B/F/M或B/F/N，而B/G集合不会递归到B/G/X，但不会递归.

The new tree walk recursively explores paths containing interesting and uninteresting trees.
Inside the trees at B, we have subtrees with names F and G.
Both sets have interesting and uninteresting paths, so we recurse into each set. This continues into B/F and B/G. The B/F set will not recurse into B/F/M or B/F/N and the B/G set will not recurse into B/G/X but not B/G/Y.

这篇关于git push对于大量仓库来说非常慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！