预测 git Push 中将推送多少数据
我偶尔会使用昂贵的互联网连接,并且我想知道(至少大约)有多少数据将在 git Push 中推送到远程。
I am occasionally on an expensive Internet connection and I would like to know (at least approximately) how much data will be pushed to the remote in a git push
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
事实上,我想我很喜欢我的评论,可以将其作为答案发布!
当您推送时,git 会创建一个包含所有必需对象的包并将其上传到远程。这意味着我们正在寻找一种方法来预测包装大小。由于包是压缩的,因此很难根据差异或对象大小执行任何操作;我们真正想做的只是看看这个包有多大。如果您可以在构建包之后中断推送,并根据包大小决定继续,那就太好了,但我认为这是不可能的。我最好的猜测是尝试重新创建将被推送的包并检查它。
捆绑文件基本上是一个带有标头信息的包(请查看 来源(如果您愿意的话)。这意味着它是一个方便的瓷器命令,可以创建您关心的大小的文件。 (比尝试使用 pack-objects< 容易得多/a> 手动。)使用类似这样的东西:
这将为您提供一个包,其中包含掌握 master 所需的所有内容,前提是远程具有 origin/master - 与应由 git push origin 推送的内容完全相同大师。如果你还有额外的分支要推,你也可以把它们粘上去;它只是采用 rev-list 参数:
只需检查创建的包的大小;它应该几乎等于你最终要推动的东西。这确实意味着您最终必须创建两次包(一次是捆绑包,一次是推送),但除非这是一个真正大的推送,需要很长时间才能打包,否则这不应该是一个巨大的问题。
Actually, I think I like my comment enough to post it as an answer!
When you push, git creates a pack of all the necessary objects and uploads that to the remote. This means we're looking for a way to predict that pack size. Since the packs are compressed, that makes it very difficult to do anything based on diffs or object sizes; what we really want to do is just see how big that pack will be. It'd be nice if you could interrupt the push, just after it's constructed the pack, and decide to proceed based on the pack size, but I don't think that's possible. My best guess is to try to recreate the pack that would be pushed and inspect that.
A bundle file is basically a pack with header information (have a look at the source if you like). This means it's a convenient porcelain command that'll create a file with the size you care about. (Much easier than trying to use pack-objects manually.) Use something like this:
That'll give you a bundle containing everything needed to get to master, given that the remote has origin/master - exactly the same thing that should be pushed by
git push origin master
. If you have additional branches you'll be pushing, you can tack them on as well; it's just taking rev-list args:Just check the size of that created bundle; it should be nearly equivalent to what you'll end up pushing. This does mean that you'll end up having to create the pack twice (once with the bundle and once with the push), but unless this is a really big push which takes a long time to pack up, that shouldn't be a huge problem.
您可以通过运行与 Git 在创建要推送的包文件时在内部运行的类似的 Bash 来找到非常准确的信息:
这应该输出 Git 将发送的包文件的字节数。分解:
这是在推送之前执行
git fetch
的条件;如果不这样做,Git 将无法找到共同祖先,并将发送整个存储库的内容。请参阅此答案< /a> 了解更多信息。You can find out pretty much exactly by running a similar bit of Bash to what Git will run internally when it creates the pack file to push:
This should output the byte-count of the pack file Git would send. Broken down:
This is conditional on doing a
git fetch
right before you push; if you don't, Git won't be able to find the common ancestor and will send the contents of your entire repository. See this answer for more info.