<div dir="ltr"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 18 October 2018 at 17:52, Duncan P. N. Exon Smith via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br><div>(Side note: growing .git/objects from 616M to 960M seemed unexpectedly high to me given that ~300M should only have included commit objects (since the tree objects should be shared).  Fortunately, repacking gives better results:</div><div>```</div>$ git repack -ad<br>Counting objects: 3503266, done.<br>Delta compression using up to 8 threads.<br>Compressing objects: 100% (699515/699515), done.<br>Writing objects: 100% (3503266/3503266), done.<br><div>Total 3503266 (delta 2744501), reused 3501658 (delta 2743526)</div><div>$ du -hs .git/objects<br>678M<span class="gmail-m_-8426741083983991450Apple-tab-span" style="white-space:pre-wrap">        </span>.git/objects<br>```</div><div>Vendors that want to merge a downstream vendor branch with the new monorepo can just repack after the initial merges.)</div><div><br></div></div></div></blockquote><br></div></div><div class="gmail_extra">`git fetch` (well, fetch-pack / upload-pack) works out which objects to include based on finding commits both endpoints know about.</div><div class="gmail_extra">But in this case the commits are all different, even though the trees should be identical.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">If you wanted to reduce pack size and transfer bandwidth for users making the switch, you could build a temporary repository that had both sets of histories.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> <br></div></div></div>