TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Going down the rabbit hole of Git's new bundle-URI

293 点作者 chmaynard2 个月前

8 条评论

jakub_g大约 2 个月前
This is super interesting, as I maintain a 1M commits &#x2F; 10GB size repo at work, and I&#x27;m researching ways to have it cloned by the users faster. Basically for now I do a very similar thing manually, storing a &quot;seed&quot; repo in S3 and having a custom script to fetch from S3 instead of doing `git clone`. (It&#x27;s faster than cloning from GitHub, as apart from not having to enumerate millions of objects, S3 doesn&#x27;t throttle the download, while GH seem to throttle at 16MiB&#x2F;s.)<p>Semi-related: I always wondered but never got time to dig into what exactly are the contents of the exchange between server and client; I sometimes notice that when creating a new branch off main (still talking the 1M commits repo), with just one new tiny commit, the amount of data the client sends is way bigger than I expected (tens of MBs). I always assumed the client somehow established with the server that it has a certain sha, and only uploads missing commit, but it seems it&#x27;s not exactly the case when creating a new branch.
评论 #43383610 未加载
评论 #43383711 未加载
评论 #43390898 未加载
评论 #43385889 未加载
评论 #43385458 未加载
评论 #43385872 未加载
评论 #43383826 未加载
评论 #43391825 未加载
ks2048大约 2 个月前
How much bandwidth and time is wasted cloning the entire history of large projects when people only need single snapshot in a single branch?<p>According to SO, newer versions of git can do,<p><pre><code> git init git remote add origin &lt;url&gt; git fetch --depth 1 origin &lt;sha1&gt; git checkout FETCH_HEAD</code></pre>
评论 #43383901 未加载
评论 #43383891 未加载
评论 #43384136 未加载
autarch大约 2 个月前
&gt; This has resulted in a contender for the world&#x27;s smallest open source patch:<p>Hah, got you beat: <a href="https:&#x2F;&#x2F;github.com&#x2F;eki3z&#x2F;mise.el&#x2F;pull&#x2F;12&#x2F;files" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;eki3z&#x2F;mise.el&#x2F;pull&#x2F;12&#x2F;files</a><p>It&#x27;s one ASCII character, so a one-byte patch. I don&#x27;t think you can get smaller than that.
评论 #43385424 未加载
评论 #43383580 未加载
评论 #43383566 未加载
评论 #43385824 未加载
评论 #43383400 未加载
评论 #43424937 未加载
geenat大约 2 个月前
git needs built in handling of large binary files without a ton of hassle, it&#x27;s all I ask. It&#x27;d make git universally applicable to all projects.<p>mercurial had it for ages.<p>svn had it for ages.<p>perforce had it for ages.<p>just keep the latest binary, or last x versions. Let us purge the rest easily.
评论 #43386667 未加载
评论 #43384404 未加载
评论 #43386436 未加载
robertlagrant大约 2 个月前
Nothing to do with the article, but I appreciate the slightly idiosyncratic GitButler YouTube videos that explain how bits of Git work.
评论 #43387506 未加载
andrewshadura大约 2 个月前
Interestingly, Mercurial had solved the bundles more than ten years ago and back then they already worked better than Git&#x27;s today
评论 #43383635 未加载
评论 #43383827 未加载
评论 #43389710 未加载
评论 #43383634 未加载
mbac32768大约 2 个月前
One consequence of git clone is that if you have mega repos, it kind of ejects everything else from your cache for no win.<p>You&#x27;d actually rather special case full clones and instruct the storage layer to avoid adding to the cache for the clone. But this isn&#x27;t always possible to do.<p>Git bundles seem like a good way to improve the performance of other requests, since they punt off to a CDN and protect the cache.
jedimastert大约 2 个月前
This actually might solve a massive CI problem we&#x27;ve been having...will report back tomorrow
评论 #43383393 未加载