如果不是最新的，阻止git push发送整个repo [英] Preventing git push from sending entire repo if not up-to-date

问题描述

相关问题：为什么

当使用两个Git仓库时， ，即使99％的提交对象是相同的，当 origin时使用 git push 发送提交到资源库

更长的版本：我们在我们的持续集成服务器上设置了第二个Git存储库。在我们在本地准备好提交对象之后，而不是像通常那样直接推送到 origin / master ，而是将更改推送到第二个存储库上的分支。 CI服务器拾取新分支，将其自动重命名为 master ，运行我们的集成测试，如果一切正常，将分支推送到

CI服务器还定期调用 git fetch 从主仓库检索 origin / master 的最新副本，以防有人完成CI过程并直接推送。

这工作奇妙，特别是如果一个 git fetch; git rebase origin / master ，然后再推送到CI库; Git只发送不在 origin / master 中的提交对象。如果在push之前跳过fetch / rebase步骤，进程仍然可以工作，但是Git似乎发送，如果不是全部，那么大多数提交对象到CI repo目前超过200MB的价值。 （我们的仓库的一个新克隆在225MB。）

我们做错了什么？是否有一种方法来纠正这种行为，使Git只发送它需要的提交对象形成CI回购的分支？我们显然可以解决这个问题，做一个预推动 git fetch; git rebase origin / master ，但是感觉我们应该可以跳过这一步，特别是因为直接推送到master repo不会出现同样的问题。

我们的回复由Gitosis 0.2提供，我们的客户端压倒多数地运行msysgit 1.7.3.1-preview。

解决方案

事实证明，这个问题的最简单的解决方案是在下一步之前获取：

  $ git fetch origin master 
 $ git push user @ host：repo.git HEAD：refs / heads / commit128952690069 
  

在我们的例子中，重要的是获取一个特定的分支到 FETCH_HEAD ;以这种方式，用户的本地分支状态将不受影响，但是我们仍然从主存储库接收最新的对象集合;当Git开始打包对象时，以下 git push 将始终具有祖先提交。

使用 git pack-objects ：如果一个文件包含提交< common_ancestor>。HEAD ，它只打包所需的数据：

  $ echo $（git merge-base master origin / master） HEAD | git pack-objects --revs --thin --stdout --all-progress-implied> packfile 
  

但是，发出 git push

我怀疑发生了什么情况是在连接到Git仓库后，一个在repo中接收最新版本的SHA - 如果Git本地没有由SHA表示的提交对象，它不能运行 git merge-base 来确定公共祖先;因此，它必须将所有对象发送到远程仓库。如果该提交对象存在，则 git merge-base 成功，并且可以构建引用共同祖先的包文件。

Related question: why does Git send whole repository each time push origin master

The short version: When working with two Git repositories, even if 99% of the commit objects are identical, using git push to send a commit to repository B when origin is set to point to repo A causes all objects (200MB +) to be transferred.

The much longer version: We have a second Git repository set up on our continuous integration server. After we have prepared our commit objects locally, instead of pushing directly to origin/master as one normally would, we instead push our changes to a branch on this second repository. The CI server picks up the new branch, auto-rebases it onto master, runs our integration tests and, if all is well, pushes the branch to origin/master on the master repo.

The CI server also periodically calls git fetch to retrieve the latest copy of origin/master from the master repo, in case someone has gone around the CI process and pushed directly.

This works wonderfully, especially if one does a git fetch; git rebase origin/master before pushing to the CI repo; Git only sends the commit objects that are not already in origin/master. If one skips the fetch/rebase step before pushing, the process still works, but Git appears to send, if not all, then a majority of commit objects to the CI repo -- currently more than 200MB worth. (A fresh clone of our repo clocks in at 225MB.)

Are we doing something wrong? Is there a way to correct this behaviour such that Git only sends the commit objects it needs to form the branch on the CI repo? We can obviously work around the issue by doing a pre-push git fetch; git rebase origin/master, but it feels like we should be able to skip that step, especially because pushing directly to the master repo does not present the same problem.

Our repos are served up by Gitosis 0.2, and our clients are overwhelmingly running msysgit 1.7.3.1-preview.

解决方案

It turns out the simplest solution to this problem is to fetch right before the push:

$ git fetch origin master
$ git push user@host:repo.git HEAD:refs/heads/commit128952690069

In our case, it's important to fetch a specific branch into FETCH_HEAD; in this way, the user's local branch state will be unaffected, but we still receive the most up-to-date set of objects from the main repository; the following git push will always have the ancestor commit present when the Git starts to pack objects.

I did some tooling around with git pack-objects: if one builds a pack file containing the commits <common_ancestor>..HEAD, it only packs as much data as is required:

$ echo $(git merge-base master origin/master)..HEAD | git pack-objects --revs --thin --stdout --all-progress-implied > packfile

However, issuing git push with the repository in the same state causes all objects to get packed and sent.

I suspect what happens is that upon connecting to the Git repo, one receives the SHA of the latest revision in the repo -- if Git does not have the commit object represented by that SHA locally, it cannot run git merge-base to determine the common ancestor; therefore, it must send all the objects to the remote repo. If that commit object does exist, then git merge-base succeeds, and the pack file can be built referencing the common ancestor.

这篇关于如果不是最新的，阻止git push发送整个repo的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！