Today, we hosted the 15th annual Microsoft Ability Summit, with over 20,000 attendees from 164 countries coming together virtually to discuss the future of AI and accessibility. Microsoft has a long-standing commitment to investing in accessibility, grounded in our business model and going back over three decades from the earliest accessibility features in Windows 95 and continuing today with new hardware and software functionalities powered by AI. We are innovating faster than ever before and people with disabilities continue to lead the way. Accessibility is a fundamental right for people with disabilities and makes technology easier for everyone. We see this reflected in how customers are using Microsoft technologies around the world. Copilot for Microsoft 365 is unlocking workplace productivity like never before, more than 10 million people use Edge each month to have the web Read Aloud, over 1 million people use Immersive Reader to make webpages easier to read and partners like Tobii Dynavox and Special Olympics are bringing AI to people with disabilities globally. And these are just some of the highlights of what we shared today! Here’s a quick summary of the new accessibility products, features and programs announced at the 2025 Ability Summit. What’s new in 2025? We announced that the Xbox Adaptive Joystick is now available for purchase exclusively at Microsoft Store. With more than 429 million players with disabilities worldwide, we know each player has unique needs and preferences for how they choose to play. The Xbox Adaptive Joystick is a singular, wired controller primarily designed to meet the needs of players with limited mobility. Its versatility helps players seamlessly incorporate it into their existing gaming setups. Built with the Gaming and Disability community who inform the development of Xbox products from the beginning. The joystick joins our family of adaptive accessories including the mouse, pen, adaptive kit and Xbox Adaptive Controller. For more details visit Xbox Support. And all our Microsoft hardware comes in packaging designed to be accessible and sustainable. No more plastic clamshells! To help others with accessible packaging, today at the Summit, the Packaging and Content Team at Microsoft published its Accessible Packaging Design Guide, which offers practical guidelines, best practices and strategies to create accessible packaging and foster a trusted customer experience. At the Summit, Microsoft teams and partners also shared ways they are working to further advance accessibility through technology: Tobii Dynavox is integrating Microsoft Neural Voice, a capability of Azure AI Speech, into their assistive communication solutions. This AI-powered feature gives more personal options for individuals who use assistive communication devices using eye gaze. Neural Voices are available in over 50 languages within their apps TD Talk and TD Phone. Microsoft Teams will improve for those using Sign Language View. Later this year, Teams will be able to identify when someone is using sign language and feature them prominently as a speaker in the meeting. These video customizations are part of our ongoing product development to help deliver clear and accessible communication for everyone. Copilot is powering neurodiverse talent. Recently, an EY study found that Copilot helped 76% of neurodiverse employees perform better at work by enhancing communication, memory recall and focus. At the Summit, we shared how new simple features like Team Reflow and PowerPoint Designer are helping people do their work. See four early adopters of Copilot in New York share their stories. YouTube Video Click here to load media AI comes to Narrator. Rich image descriptions powered by AI will be coming to Narrator in Windows Insider Preview this spring and Azure AI Foundry announced new UI improvements to reduce cognitive load. Over 5 million learners around the world have participated in our Accessibility Skilling program and we’re grateful to our partners including Teach Access, Computacenter UK and the City of New York. The free, virtual training includes the latest on AI and is available for organizations to use in their learning management systems. Speech recognition improved up to 60%. The Speech Accessibility Project, led by the University of Illinois Urbana-Champaign, unlocked a breakthrough improving accuracy gains for non-standard speech, and the Azure platform team demonstrated how developers can leverage GitHub Copilot to write accessible code. Special Olympics shared how Copilot has been a game-changing training companion for their coaches and athletes with intellectual and development disabilities for the Special Olympics World Winter Games in Turin, Italy. All this progress is possible because of the people who design technology with accessibility in mind. In this way, technology benefits everyone, creating a more productive and efficient workplace. It is beautiful to see that reflected in this profile of Dave Dame, Senior Director of Accessibility and Human Factors at Microsoft, where he shared how accessible technology helps him thrive as a leader. Onward For over 30 years, Microsoft has focused on accessibility in our products. Accessibility makes our tools and technologies easier for everyone and accelerates innovation for the world. From the introduction of Sticky Keys and speech recognition in Windows 95 to Seeing AI in 2016 and beyond, accessibility innovations have benefited people in ways we designed for and ways we could have never expected. Just think about how closed captions are now invaluable for everyone watching videos and calls. AI has the potential to create significant advancements across every sector of our economy and society. We will continue to be grounded and responsible in our approach as we work to get the latest technology to the people who can benefit from it the most. Whether this is your first or fifteenth Ability Summit, thank you for joining and we hope you picked up a new feature, skill or nugget that helps you, your community or your organization get the most out of technology. All content will be available to watch after the event. Let’s move forward together. The post Microsoft Ability Summit 2025: Accessibility in the AI era appeared first on The Official Microsoft Blog. ​Today, we hosted the 15th annual Microsoft Ability Summit, with over 20,000 attendees from 164 countries coming

Alienware is unveiling a lineup of six new gaming monitors and launching its highly anticipated Alienware 27 4K QD-OLED Monitor.

Here’s how Samsung SDS and Dell Technologies are collaborating to pave the way for “AI Life.”

Discover how NEC and Dell are transforming 5G for CSPs with certified solutions that simplify deployment and scale with ease.

GPU acceleration transforms data workflows for speed, scalability, and actionable insights in AI and GenAI projects.

Remember when creating a video game required a full studio and millions in funding? Those days may be ending.

In today’s fast-paced world where collaboration between technical and non-technical teams is vital, tools like GitHub Copilot are proving to be indispensable. These AI-powered tools are no longer just the secret weapons of developers—they’re becoming essential productivity boosters for product managers, program managers, security professionals, scrum masters, community managers, and quality analysts alike. While Copilot is widely praised for its role as a pair programmer, its potential stretches far beyond writing code. From automating tedious tasks to making complex processes more accessible, this tool is transforming how non-technical professionals tackle their daily challenges. Let’s take a look at how GitHub Copilot makes it easier for teams to work smarter, solve problems faster, and accomplish more together. 💪 Generating and reformatting Markdown When working in GitHub, writing Markdown is a necessity. Whether you’re adding documentation, creating a report, opening an issue, or starting a discussion on GitHub, it’s all done in Markdown. This can be overwhelming when getting started, as Markdown requires familiarity with its syntax to add elements like headers, tables, lists, hyperlinks, and images, to name a few. Copilot can significantly ease this process by generating a template to work from, allowing you to focus on the content rather than the formatting. For example, let’s say you’re tasked with creating a fresh new README for your team’s repository. You can quickly generate a template using a prompt like this: Create a README file for my team’s GitHub repo. The file should include sections for our team’s objective, a link to our project’s roadmap, and a team roster. The team roster should include small versions of our GitHub profile pictures, using ashtom as a placeholder, as well as the person’s name and role. https://github.blog/wp-content/uploads/2025/03/1.-Generating-and-reformatting-markdown-1-of-3.mp4#t=0.001 While this is a great start, you can further optimize Copilot by adding some of GitHub’s Markdown syntax documentation to your Copilot custom instructions file. With this change you’ll find that Copilot is more likely to include GitHub-specific Markdown styling like alerts, emojis, and color models that make your content pop. Copilot can also take raw, unstructured data and format it into Markdown. For example, maybe you have some notes captured in a separate application and you’re looking to move those notes into GitHub. Skip the intricate reformatting step by asking Copilot to do it for you: Reformat the following content into Markdown code: <paste in raw unstructured notes> And within seconds you’ll have a new version of your notes that are ready to make their way into a Markdown file, issue, or discussion: Reviewing content with Copilot On top of helping you write and format content, Copilot can review content for typos, style, and clarity. And let’s face it, after working on the same document for hours a second set of eyes can go a long way. To start a Copilot review, highlight all of the text that you want Copilot to analyze, right click and select the Copilot sub-menu and click Review and Comment. You can further customize Copilot’s review instructions by configuring the Copilot Chat settings in VS Code. This is great when you want Copilot to critique your work in specific ways like having Copilot assume a certain role, or encouraging Copilot to think about a specific target audience. Automating reporting and spreadsheet manipulation Working with spreadsheets is a crucial yet time-consuming task for many professionals, especially project managers and security analysts. Whether it’s tracking project progress, generating compliance reports, or analyzing security logs, manually processing data can be a tedious and error-prone process. With GitHub Copilot, you can automate these repetitive tasks, streamline data manipulation, and generate reports faster—all with AI-assisted code suggestions. With just a beginner level understanding of Python, Copilot can teach you how to code as it helps you write a script to process and manipulate your files. Let’s take a look at how to do that in action, starting with a prompt that clarifies your experience and intent: Create a Python script that parses this CSV file and creates new CSV files for each unique Assignee with their tasks. Let’s think step by step. Explain the steps as if I have no prior experience with python. I’m using MacOS. Copilot explains how to perform the data manipulation with Python, as well as how to create and run a Python script. And if you run into an error, Copilot can help explain why it occurred and what you should do about it. https://github.blog/wp-content/uploads/2025/03/5.-Automating-reporting-and-spreadsheet-manipulation-1-of-1.mp4#t=0.001 Understanding code in natural language Non-technical team members often encounter snippets of code that seem like a foreign language. If you’re a community manager, for example, you might need help interpreting code while moderating discussions, assisting users, or collaborating with developers. Copilot Chat can translate that code into clear, simple language, helping you to understand its purpose without a computer science degree: Before: if (user.isAdmin) { grantAccess(); } After Copilot Chat: “This code checks if a user is an admin and grants them access if they are.” Copilot is also great at explaining what a GitHub Actions workflow does. While Actions is a great automation tool, there is certainly a learning curve associated with creating workflows. Copilot can act as a mentor, explaining what each part of the workflow does for those who are new and eager to learn. Take for example, this simple prompt to learn about an Actions workflow that has something to do with stale issues and pull requests: What does this workflow file do? Explain it as if I had no prior GitHub Actions experience. https://github.blog/wp-content/uploads/2025/03/3.-Understanding-code-in-natural-language-1-of-1.mp4#t=0.001 Creating GitHub Issue templates Issue templates are a great way to streamline the collection of information in a consistent fashion by providing a template in Markdown. Issue forms provide a more user-friendly method for gathering that information, but require knowledge of YAML and specific keywords. Copilot can help elevate your issue template game by providing the YAML boilerplate code needed for issue forms. Start by prompting Copilot with an outline of what you want to achieve, being as specific as possible about default labels,

In February, we experienced two incidents that resulted in degraded performance across GitHub services. February 25 14:25 UTC (lasting 2 hours and 19 minutes) On February 25, 2025, between 14:25 UTC and 16:44 UTC, email and web notifications experienced delivery delays. At the peak of the incident, the delay resulted in ~10% of all notifications taking over 10 minutes to be delivered, with the remaining ~90% being delivered within 5-10 minutes. This incident was caused by worker pools running too close to capacity at peak times, resulting in a delay in queue processing. We mitigated the incident by scaling out the service to meet the demand. We’ve since established a higher baseline capacity to ensure no further delays occur, and we are improving our capacity planning to proactively manage our pool going forward. February 3 18:01 UTC (lasting 30 minutes) On February 3, 2025, at 18:01 UTC, an incident was declared due to failures in our Migration Tools. The root cause was traced to a deployment of a system component, which led to missing Docker images, causing a 100% outage for all users attempting migrations in this window. The issue was mitigated by rolling back to the previous stable version, restoring service within approximately 30 min. We have enhanced our test coverage and our workflows to ensure validation of critical dependencies. Please follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the GitHub Engineering Blog. The post GitHub Availability Report: February 2025 appeared first on The GitHub Blog.

Here’s a true story: I learned Java after pretending to be an Android developer when I first started out in software development. While doing that, I quickly learned something important: Java isn’t just a convenient entry point into tech, it’s a strategic career choice. That’s why I want to examine what makes Java so interesting—and how you can either get started or brush up on your skills. After all, when you are trying to break into tech, especially when you’re coming from a non-traditional background like me (I began my career as an Army soldier and construction manager), you need a language that’s both learnable and employable. And, in my experience, knowing your way around Java opens doors that might otherwise stay closed to a newcomer. So, let’s jump in. What is Java? And what’s the difference between Java and JavaScript? When we think about the programming languages that form the backbone of enterprise software development, Java is one of the first names that comes to mind. At its core, Java is a versatile, object-oriented programming language, rooted in its “write once, run anywhere” (WORA) strength. Thanks to the Java Virtual Machine (JVM), it powers the foundation for scalable, secure applications across nearly every industry. Despite sharing part of its name with JavaScript, Java serves a distinctly different purpose. JavaScript is a lightweight language used predominantly for front-end web development, backend work, and full-stack applications. Meanwhile, Java is a general purpose language that is used for everything from backend development to desktop applications, mobile apps, and large-scale enterprise applications. Today, Java powers everything from your Spotify playlist in Android mobile to the Cash App transaction to split your dinner check. In short, Java powers massive systems that process millions of data transactions every day. And let’s clear something up: if you’re picturing verbose enterprise code running on dusty servers, it’s time for an update. Java has evolved from its enterprise roots, where it was largely used for powering payroll systems and customer databases, into a versatile platform driving everything from backend services to gaming to AI-powered applications such as Netflix and LinkedIn. With a history spanning three decades, Java has proven itself as a reliable, versatile, and constantly evolving language that continues to be a top choice for developers around the world. So, what is it about Java that has not only endured but thrived in an environment full of constant change? To understand this resilience and versatility, let’s take a step back and look at where Java came from and how it has grown over the years. The birth of Java: write once, run anywhere Java’s story begins back in 1991 when a team of engineers at Sun Microsystems, led by James Gosling, set out to create a language for interactive television. First developed under the name Oak, the language that would be renamed Java was designed to be simple, robust, and platform independent, using a virtual machine—later called a Java Virtual Machine, or JVM—to run code anywhere. While that original project didn’t quite pan out, it laid the groundwork for something much bigger. In 1995, Java 1.0 was officially released, and with it came a revolutionary promise: “Write Once, Run Anywhere” (WORA). This principle meant Java code could be written once and then run on any device that supports the Java platform, without needing to be recompiled for each operating system. Fun fact 💡 The name “Java” wasn’t the original choice for the language. In 1991, the project was initially called “Oak” by James Gosling and his team at Sun Microsystems, named after an oak tree outside Gosling’s office window. However, they discovered that Oak was already trademarked by another company. To fully appreciate the impact of this shift, it’s helpful to look back at the state of software development in the mid ‘90s. If you were a developer back then and you wanted your application to run on multiple operating systems (Windows, Mac, and Unix), you needed to write separate versions for each one. This meant learning the unique APIs, libraries, and quirks of each operating system—which was even more fun then than it is now (seriously, it was a slog). Updating and fixing had to be done platform by platform in a tedious grind like a messy game of Whac-A-Mole. One fix here, another patch there, and plenty of ways for things to go wrong. This fragmented approach was a significant barrier to building software for a wide, diverse audience. For enterprises looking to deploy applications across multiple environments, Java became an incredibly attractive choice. With the emergence of enterprise-focused frameworks like J2EE and Spring, coupled with strong corporate backing from Sun Microsystems and later Oracle, it provided the reliability and consistency that businesses needed. From complex to clear: Java’s evolution for new developers After 30 years, you might just say that Java has come a long way from its early days. Let’s take the release of Java 23 in September 2024 as an example. This update brought a host of new features and enhancements designed to make developers’ lives easier while keeping Java aligned with the needs of modern development. This included enhancements such as: Primitive types in patterns, instanceof, and switch (Preview – JEP 455), which allows primitive types like int and double to be used seamlessly with pattern matching and switch statements, simplifying code and reducing workarounds Markdown documentation comments (JEP 467), which lets developers write Java Docs using Markdown syntax to create more readable documentation directly in the source code One of the most notable changes was the simplification of the language’s entry point for new developers. The classic “Hello, World!” program, which is often the first thing a developer writes when learning a new language, was streamlined to just a few lines of code. The traditional version required understanding several complex concepts right from the start. Need proof? Here’s the old way: public class HelloWorld { // A class declaration that must match the file name public static void main(String[]

This post originally appeared in Infosecurity Magazine, and is republished here with permission. In the fast-paced world of software development, accidents can happen—even to the best of us. One such unfortunate event is the accidental leakage of sensitive data such as private or internal source code. When this occurs, companies often find themselves in a frantic rush to assess the situation, leading them down the rabbit hole of trying to determine just how exposed their sensitive data really is. However, this quest for degrees of exposure is a futile endeavor. There’s no such thing as “just a little bit exposed.” Instead, it’s better to opt for the more pragmatic approach: treat the exposure as full and complete from the moment it happens. The futility of chasing degrees of exposure Imagine your company’s sensitive data accidentally ends up in the public domain. An employee, for example, mistakenly posted it to a public repository. Panic sets in, and the first instinct is often to try and measure the extent of the exposure. Who accessed it? For how long? Did anyone download it? These questions are perfectly logical, but they’ll lead you down a time-consuming and fruitless path. The reality is the moment your sensitive data is public, it’s out there for anyone to see. The internet is a vast and anonymous space, and trying to pinpoint the exact degree of exposure can quickly become an exercise in chasing shadows. Treating exposure as inevitable Instead of dwelling on the question of “how exposed” you are, we should assume the worst from the outset. Your sensitive data is fully exposed; consider it a given. Embrace this assumption, and you can start taking practical steps to mitigate the potential fallout. Practical steps for moving forward Rotate exposed secrets: If your sensitive data contained secrets such as API keys or personal access tokens, assume that these have been compromised. Immediately rotate these secrets to prevent unauthorized access. Some data may need to be removed entirely. Assess impact: Focus on understanding the potential impact of the exposure. What vulnerabilities might arise from the leaked sensitive data? Perform a thorough security assessment to identify and address potential risks based on the premise that the sensitive data was fully exposed to the public. Communication: Transparent communication with stakeholders, customers, and the public is essential. Inform them of the situation, the steps you’re taking to mitigate risks, and any potential actions they should take. Legal considerations: Consult with legal experts to understand any legal ramifications of the leak. This could include potential intellectual property issues or contractual obligations. The benefits of treating exposure as full Speed: By assuming full exposure, you can act swiftly to mitigate risks and minimize potential damage. Clarity: There’s no ambiguity. You don’t waste time trying to determine the extent of exposure. Security: Rotating exposed secrets and conducting a thorough security assessment are prudent measures that enhance your overall security posture. Take this with you When it comes to handling sensitive data leaks, it’s time to shift our default mindset. Instead of asking “how exposed,” we should embrace the assumption of full exposure. By doing so, we can respond more effectively and focus on what truly matters: securing our systems, protecting sensitive data, and maintaining the trust of our stakeholders. In the world of cybersecurity, assuming the worst from the outset is a pragmatic approach that benefits developers and organizations alike. Avoid the exposure of private or sensitive data.Check out our best practices for preventing data leaks in your organization. The post Full exposure: A practical approach to handling sensitive data leaks appeared first on The GitHub Blog.

Open source projects generally begin with a problem to be solved. If it’s a problem a lot of people have, it may gain traction. Eventually you might have many people contributing. Before you know it, your project might turn into more than just a project, but a community. That requires you as a maintainer to think differently about what you’re doing. It’s no longer just about writing code, but about facilitating relationships. In this article, we’ll explore four steps to take to help your open source project evolve into a healthy community. 1. Lay the ground work early It’s never too early to start thinking about community. The Astro team had community building in mind from the very beginning of the project. “It was one of the first things we focused on once we had a minimum viable product (MVP) together,” Astro co-creator Fred Schott told us in a Q&A on open source community building. There’s quite a bit you can do to prepare before people start showing up. Among the most important is creating contributor guidelines and adopting a code of conduct. “You’d be surprised at how early contributor guidelines come in handy,” Schott says. “You need to answer questions like ‘How do I clone the repo?’ or ‘How do I get the packages installed?’” These basic things might seem obvious. But maintainers have been in their codebases for so long that they forget how hard it can be for new people to get started. Many maintainers think a code of conduct isn’t something they need to worry about when the project is small and conflicts between contributors have yet to arise. But it’s best to have clearly articulated expectations and a plan for what to do if someone violates them before they are needed. “If you care about outside contributions at all, you should have a code of conduct, regardless of size,” Schott says. “It’s more about intent: If your goal is to build a community or encourage outside contributors on your project, then you’ll want a code of conduct. If your repo is meant to be a solo project, then I think you’re fine to skip it.” 2. Meet people where they are Building your own community spaces on platforms like Discord, Slack, and GitHub Discussions is important, but in the early days you need to meet people where they are. Graphile co-maintainer Jem Gillam says the team used F5bot to watch for mentions of Graphile across the web and social media so the team could answer questions and join conversations where they were already taking place. Eventually, as a project grows, a community will cohere in a particular place. Think offline, too. Conferences and meetups are a great way to meet current and potential users and contributors. “I go to conferences and let people know that we’re looking for contributors and that we’ll walk anyone through submitting their first pull request,” says dbatools creator and maintainer Chrissy LeMaire. “I entice people by letting them know they can safely cut their teeth with us.” 3. Lead by example Having a code of conduct is one thing. But it’s more important to conduct yourself the way you want your community to act. Schott emphasizes the importance of being patient with new users. “If you’re dismissive of the problems people face, they’ll leave,” he says. “First impressions are important.” It’s important to set the right tone. “If there’s something that has come up that’s really negative, we tend to give it time—we don’t react in the moment,” Gillam says. The team strives to assume good intent because often people might come across more harshly than they intend, especially if they’re not writing in their native language. “It’s very easy for people to think they have a silly question, but we encourage people to ask them anyway because if one person has a particular question other people probably do as well,” Gillam says. LeMaire recommends being open about what you don’t know and where you personally struggle. She livestreamed her work on Twitch to show people that even as a Microsoft Most Valuable Professional and GitHub Star she still struggled and made mistakes. “I show people that it’s OK not to know everything and that they don’t have to use the most intimidating or complicated tools to be effective,” she says. 4. Spotlight your contributors Be sure to show your appreciation for your contributors. You can thank them in the README file on your repo. LeMaire set up a LinkedIn company for dbatools and told contributors they were welcome to add themselves. It helped contributors spotlight their contributions outside of GitHub, and even helped some find jobs. Don’t forget to recognize the non-code contributors as well. “Our documentation used to assume that core contributors were technical contributors, so we had some technical requirements,” Schott explains. Initially, the Astro project required someone to make “significant code contributions” to become a core contributor. Now the team evalutates non-code contributions when considering whether to promote someone to core contributor status. “People contribute in lots of different ways, from documentation to community support,” Schott says. “We’ve updated our expectations accordingly.” Get started contributing to open source now! The post Four steps toward building an open source community appeared first on The GitHub Blog.

The open source Git project just released Git 2.49 with features and bug fixes from over 89 contributors, 24 of them new. We last caught up with you on the latest in Git back when 2.48 was released. To celebrate this most recent release, here is GitHub’s look at some of the most interesting features and changes introduced since last time. Faster packing with name-hash v2 Many times over this series of blog posts, we have talked about Git’s object storage model, where objects can be written individually (known as “loose” objects), or grouped together in packfiles. Git uses packfiles in a wide variety of functions, including local storage (when you repack or GC your repository), as well as when sending data to or from another Git repository (like fetching, cloning, or pushing). Storing objects together in packfiles has a couple of benefits over storing them individually as loose. One obvious benefit is that object lookups can be performed much more quickly in pack storage. When looking up a loose object, Git has to make multiple system calls to find the object you’re looking for, open it, read it, and close it. These system calls can be made faster using the operating system’s block cache, but because objects are looked up by a SHA-1 (or SHA-256) of their contents, this pseudo-random access isn’t very cache-efficient. But most interesting to our discussion is that since loose objects are stored individually, we can only compress their contents in isolation, and can’t store objects as deltas of other similar objects that already exist in your repository. For example, say you’re making a series of small changes to a large blob in your repository. When those objects are initially written, they are each stored individually and zlib compressed. But if the majority of the file’s content remains unchanged among edit pairs, Git can further compress these objects by storing successive versions as deltas of earlier ones. Roughly speaking, this allows Git to store the changes made to an object (relative to some other object) instead of multiple copies of nearly identical blobs. But how does Git figure out which pairs of objects are good candidates to store as delta-base pairs? One useful proxy is to compare objects that appear at similar paths. Git does this today by computing what it calls a “name hash”, which is effectively a sortable numeric hash that weights more heavily towards the final 16 non-whitespace characters in a filepath (source). This function comes from Linus all the way back in 2006, and excels at grouping functions with similar extensions (all ending in .c, .h, etc.), or files that were moved from one directory to another (a/foo.txt to b/foo.txt). But the existing name-hash implementation can lead to poor compression when there are many files that have the same basename but very different contents, like having many CHANGELOG.md files for different subsystems stored together in your repository. Git 2.49 introduces a new variant of the hash function that takes more of the directory structure into account when computing its hash. Among other changes, each layer of the directory hierarchy gets its own hash, which is downshifted and then XORed into the overall hash. This creates a hash function which is more sensitive to the whole path, not just the final 16 characters. This can lead to significant improvements both in packing performance, but also in the resulting pack’s overall size. For instance, using the new hash function was able to improve the time it took to repack microsoft/fluentui from ~96 seconds to ~34 seconds, and slimming down the resulting pack’s size from 439 MiB to just 160 MiB (source). While this feature isn’t (yet) compatible with Git’s reachability bitmaps feature, you can try it out for yourself using either git repack’s or git pack-objects’s new –name-hash-version flag via the latest release. [source] Backfill historical blobs in partial clones Have you ever been working in a partial clone and gotten this unfriendly output? $ git blame README.md remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) Receiving objects: 100% (1/1), 1.64 KiB | 8.10 MiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) Receiving objects: 100% (1/1), 1.64 KiB | 7.30 MiB/s, done. […] What happened here? To understand the answer to that question, let’s work through an example scenario: Suppose that you are working in a partial clone that you cloned with –filter=blob:none. In this case, your repository is going to have all of its trees, commit, and annotated tag objects, but only the set of blobs which are immediately reachable from HEAD. Put otherwise, your local clone only has the set of blobs it needs to populate a full checkout at the latest revision, and loading any historical blobs will fault in any missing objects from wherever you cloned your repository. In the above example, we asked for a blame of the file at path README.md. In order to construct that blame, however, we need to see every historical version of the file in order to compute the diff at each layer to figure out whether or not a revision modified a given line. But here we see Git loading in each historical version of the object one by one, leading to bloated storage and poor performance. Git 2.49 introduces a new tool, git backfill, which can fault in any missing historical blobs from a –filter=blob:none clone in a small number of batches. These requests use the new path-walk API (also introduced in Git 2.49) to group together objects that appear at the same path, resulting in much better delta compression in the packfile(s) sent back from the server. Since these requests are sent in batches instead of one-by-one, we can easily backfill all missing blobs in only a few packs instead of one pack per blob.