This can shave some time off your usual Git operations by itself, but where the commit-graph really shines is in the computed data it stores. With a commit-graph file, all of that information is immediate: for a given commit C, Git knows exactly where to look in a commit-graph file for all of those fields that we store, and can read them off immediately, no decompression or piecing together required.
No matter which way a commit is stored, we still have to parse and decompress it before its fields like “root tree” and “parents” can be accessed. Git stores objects in one of two ways: either as a loose object (in which case the object’s contents are stored in a single file unique to that object on disk), or as a packed object (in which case the object is assembled from a compressed format in a *.pack file). Why store all of this information? To understand the answer to this, it is helpful to have a cursory understanding of how Git stores objects.
It also stores computed information, too, like a commit’s generation number, and changed-path Bloom filters (more on that in just a moment). In essence, the commit-graph acts like a cache for commonly-accessed information about commits: who their parent(s) are, what their root tree is, and things like that. In the very simplest terms, the commit-graph file stores information about commits. (If you are familiar, and want to take a deeper dive, check out this blog post explaining all of the juicy technical details). Git 2.28 takes advantage of these optimizations to deliver a handful of sizeable performance improvements.īefore we get into all of that, it’s worth taking a refresher through commit graphs whether you’re new to the concept, or familiar with them. What does all of that mean? In a sense, this new information helps Git find points in history that touched a given path much more quickly (for example, git log -, or git blame). In Git 2.27, the commit-graph file format was extended to store changed-path Bloom filters. GitLab and Bitbucket are also making similar changes. To learn more about the complementary changes GitHub is making, see github/renaming. This change supports the many communities, both on GitHub and in the wider Git community, who are considering renaming the default branch name of their repository from master. git clone will also continue to respect the HEAD of the repository you’re cloning from, so you won’t see a change in branch names until a maintainer initiates one.
#Git config software
(For more background on this change, this statement from the Software Freedom Conservancy is an excellent place to look). In Git 2.28, a new configuration option, faultBranch is being introduced to replace the hard-coded term. When you initialize a new Git repository from scratch with git init, Git has always created an initial first branch with the name master. Here’s a look at some of the most interesting features and changes introduced since then. We last caught up with you on the latest in Git back when 2.26 was released. The open source Git project just released Git 2.28 with features and bug fixes from over 58 contributors, 13 of them new.
0 kommentar(er)
