That’s because both of those packs each have the same number of objects (in this case, just one).
Here, the progression is broken between the second and third pack. Then, adjacent packs are compared (starting with the largest packs and working toward the smaller ones) to ensure that a geometric progression exists: First, Git orders all packs (represented below by a green or red square) in ascending order based on the number of objects they contain (the numbers inside each square). To better understand how this works, let’s work through an example on seven packs. In other words, if the smallest pack has N objects, then the next-largest pack would have at least 2N objects, and so on, doubling (or growing by an arbitrary constant) at each step along the way. The idea is to determine a (small-ish) set of packs which could be combined together so that the remaining packs form a geometric progression based on object size. To do that, Git learned a new “geometric” repacking strategy. We’re working toward removing that limitation (you can read more about how we’ve done that), but one important step along the way is to implement a new repacking scheme that trades off between having a relatively small number of packs, and packing together recently added objects (in other words, approximating the new objects added since the previous repack). So if you want to use bitmaps to effectively cover many objects in your repository, those objects have to be stored together in the same pack. That’s because reachability bitmaps, which are a critical optimization for server-side Git performance, can only describe the objects in a single pack. But historically speaking, busy repositories often require that all of their contents be packed together into a single, enormous pack. So it’s often a good idea to pack everything together into one single pack. Generally speaking, Git has better performance when there are fewer packs, since many operations scale with the number of packs in a repository. Historically, git repack did one of two things: it either repacked all loose objects into a new pack (optionally deleting the loose copies of each of those objects), or it repacked all packs together into a single, new pack (optionally deleting the redundant packs). So, in case you haven’t read our earlier blog post, or just need a refresher, here are some details on geometric repacking. In Git 2.32, many of those patches were released in the open-source Git project. In a previous blog post, we discussed how GitHub was using a new mode of git repack to implement our repository maintenance jobs. Here’s a look at some of the most interesting features and changes since then. We last caught up with you on the latest in Git when 2.31 was released. The open source Git project just released Git 2.33 with features and bug fixes from over 74 contributors, 19 of them new.
0 kommentar(er)
