Eliminate context-switching during authentication development. Learn how to connect the Auth0 MCP Server to Claude Code for real-time access to the complete Auth0 documentation directly inside your terminal terminal workspace.

I keep trying to think about nothing, and it turns out thinking about nothing takes a lot of work. The moment I clear the deck and try to sit in the empty space, my mind rushes in to fill it—old conversations, half-finished projects, the next thing I am supposed to be doing, the last thing I should have done differently. Nothing is apparently the one thing my brain refuses to leave alone.

I think this is why I find the quiet so hard, and also why I keep chasing it. The work I do all day is the work of filling space—words, posts, APIs, schedules, lists, plans. Producing is easy because the machinery is always running. Stopping the machinery, even for a few minutes, is the harder discipline. It takes a lot of something to arrive at nothing.

Lately I have been treating the attempt itself as the point. I am not going to win against my own mind, but I can keep showing up to the empty room and sitting in it a little longer each time. Thinking about nothing takes a lot of work—and showing up to do that work, over and over, is exactly where the practice lives.

The Git project recently released Git 2.55.0. Let's look at a few notable highlights from this release, which includes contributions from the Git team at GitLab.

What's covered:

• git-history(1) learns fixup
• fsmonitor daemon for Linux
• git push to a remote group
• Limiting git log --graph lane width
• Evolution of Rust in the Git codebase
• Faster git-grep(1) and git-cherry(1) in partial clones

git-history(1) learns fixup

In our highlights of Git 2.54.0, we covered the introduction of git-history(1). In 2.55.0, a new subcommand for this tool was added: fixup.

Imagine you've made some changes and you want to amend those changes into an existing commit. The most common approach to this is to create a fixup commit and autosquash it with git-rebase(1):

git commit --fixup=<commit-id>
git rebase -i --autosquash <commit-id>^

Doing this in two steps is clumsy, especially because it requires an interactive rebase. Instead you can use the git-history(1) fixup command:

git history fixup <commit-id>

This takes the staged changes and amends them into the given commit. As an added bonus, because you're using git-history(1), all other local branches that contain the fixed-up commit are updated as well. So when working with stacked branches, fixup-ing a commit in the stack will automatically rebase all related branches.

This feature was implemented by Patrick Steinhardt.

fsmonitor daemon for Linux

When working with large monorepos, git-status(1) can be slow to determine what changed in the local worktree because Git would need to traverse the whole working tree to see which files are modified. To speed up this process, in January 2018 a setting core.fsmonitor was added in Git 2.16. Back then, you had to provide your own tool (like Watchman). When this was configured, this tool runs in the background and monitors changes on the file system. This informs Git that a file was touched and Git then verifies whether the file was modified and updates the cached status. Then whenever the user calls git-status(1), it can simply return the cached status.

In April 2022, the setting core.fsmonitor was changed to accept a boolean value. When this setting is set to true, a daemon built-in into Git is used and no more third-party tool is needed. But this filesystem monitor was only implemented for Windows and macOS, support for GNU/Linux did not yet exist.

This changes in Git 2.55, where support for Linux has been added, too. To achieve this, inotify(7) is used. inotify(7) was chosen over fanotify(7) because fanotify(7) requires elevated privileges. This comes with a small caveat though, the fsmonitor needs to put a watcher on each and every directory in the repository. In a large repo you might hit the limit of inotify watches (fs.inotify.max_user_watches), which you may need to raise.

These changes were submitted by Paul Tarjan based on work by Eric DeCosta and Marziyeh Esipreh.

git push to a remote group

Quite some time ago git-fetch(1) learned to fetch from a group of remotes.

The following command configures a group of remotes:

git config set remotes.forks "origin upstream"

When this is set up, you can git-fetch(1) from this "forks" group, and then all the remotes in that list are fetched from. This can be useful when you want to get the updates from a set of remotes in one go.

git-push(1), however, was not able to use remote groups.

In Git 2.55, this gap is closed and git-push(1) now accepts a remote group too. For example if you want to push the main branch to the group mentioned above:

git push forks main

Similar as with git-fetch(1), this command pushes the specified refs to each of the remotes in the group. Each remote is pushed independently and honors its own remote.<name>.push mapping and mirror settings.

This feature was submitted by Usman Akinyemi, suggested by Junio C Hamano.

Limiting git log --graph lane width

The --graph option of git-log(1) draws an ASCII representation of the commit history. In a repository with many active contributors this graph can grow very wide. For example, on the git.git repository this graph grows nine lanes wide after only 30 commits:

* 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | | cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | | ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | | 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | |   621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \ \
| * | | | | | 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_|/
| |/| | | |
* | | | | |   0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \ \
| * | | | | | 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | | | 042221cccb doc: config/sideband: fix description list delimiter
| * | | | | | 3eb61fda62 doc: config: terminate runaway lists
* | | | | | |   49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \ \ \
| * | | | | | | e8f12e0e95 t1400: have fifo test clean after itself
* | | | | | | |   b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \ \ \ \
| * | | | | | | | 55088ac8a4 describe: limit default ref iteration to tags

This happens because every lane continues downward to the commit from where the branch was created. This pushes the commit messages off to the right, making it harder to read. Especially when the terminal screen width is reached, this becomes unusable.

Git 2.55 adds a new --graph-lane-limit=<n> option to limit the number of lanes that are drawn. Any lanes beyond the limit are replaced with a ~ truncation mark, so it stays obvious that the graph was trimmed:

git log --graph --graph-lane-limit=5

Using this option for the same 30 commits as above, we'll get:

* 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | ~ cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | ~ ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | ~ 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | ~ 621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \~
| * | | | ~ 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_~
| |/| | | ~
* | | | | ~ 0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \~
| * | | | ~ 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | ~ 042221cccb doc: config/sideband: fix description list delimiter
| * | | | ~ 3eb61fda62 doc: config: terminate runaway lists
* | | | | ~ 49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \~
| * | | | ~ e8f12e0e95 t1400: have fifo test clean after itself
* | | | | ~ b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \~
| * | | | ~ 55088ac8a4 describe: limit default ref iteration to tags

The option only makes sense together with --graph. The default is 0, which means no limit, and zero or negative values are treated the same way, just like --max-parents does.

This feature was submitted by Pablo Sabater.

Evolution of Rust in the Git codebase

In March 2025, with the release of Git 2.49, the first Rust code was added to the Git codebase. Rust bindings were added to allow Rust code to call into libgit. But none of that Rust code was used by the Git binaries.

In November 2025, in Git 2.52, the first Rust production code was introduced into Git. Then a Rust implementation for the varint subsystem was added. This code is optionally compiled if the Rust compiler is available, and when it's not, the C implementation is used. This was added as a test balloon for distributors to start preparing their tooling for a Git release that requires Rust at some point.

Earlier this year, in Version 2.54, more Rust code was added to the codebase with the introduction of the ObjectID type. This was added as part of the efforts to implement interoperability between SHA-1 and SHA-256.

Until this release, both build systems Make and Meson would gracefully fall back to the C implementation if the Rust compiler is not found. With this v2.55 release the Rust compiler is required unless you explicitly disable it in the build system.

Please note that this doesn't affect users of Git. It only affects those who build Git from source. If you compile Git and don't want to use Rust, disable it with one of these commands:

# Meson
meson configure -Drust=disabled

# Makefile
make NO_RUST=YesPlease

Bringing Rust into Git has been an ongoing (and unfinished), multi-release, community effort. It's impossible to attribute this to a single person, but some of the most prominent contributors include brian m. carlson, Patrick Steinhardt, Ezekiel Newren, and Calvin Wan.

Faster git-grep(1) and git-cherry(1) in partial clones

git-clone(1) has this feature called partial clone. This allows the user to apply a filter to what is sent over from the server. In practice, this is done with the --filter option. For example:

git clone --filter=blob:none <remote>

This will clone the repository, but that clone excludes all blobs (i.e. the contents of the files in the tree). This can speed up the clone tremendously, but it comes at the cost that Git needs to download blobs later when other commands are used that read file contents. And some commands might need a lot of missing blobs.

git-grep(1) is one of those commands, as it searches the content of the files. To do so, it obviously needs to have those files. Imagine you want to search the word "TODO" 100 commits back in history:

git grep TODO HEAD~100

This command resolves the HEAD~100 commit and the trees associated with that. But those trees might point to blobs that aren't downloaded yet. Previously, each blob was downloaded separately. But that is improved in Git 2.55. In this version of Git, the blob downloads are batched together into a single negotiating round-trip with the server.

This batching is now implemented for both git-grep(1) and git-cherry(1).

This change was submitted by Elijah Newren.

Read more

This article highlighted just a few of the contributions made by GitLab and the wider Git community for this latest release. You can learn about these from the official release announcement of the Git project. Also, check out our previous Git release blog posts to see other past highlights of contributions from GitLab team members.

At Microsoft Build 2026, we introduced WSL containers, bringing Linux container development directly into Windows through the Windows Subsystem for Linux (WSL). Containers have become a foundational part of modern development – from cloud-native applications and AI workloads to testing and deployment pipelines and WSL containers simplify this experience by providing a built-in, enterprise-ready way to create, run, and manage Linux containers on Windows, without requiring additional third-party tooling.

With a new container CLI for end-to-end container workflows and an API that enables Windows applications to programmatically leverage Linux containers, WSL containers make it easier for developers and organizations to build, test, and run containerized workloads while benefiting from the security, manageability, and integration of the Windows platform.

You can now access the WSL container feature in our latest pre-release of WSL! You can install this release right away by running wsl --update --pre-release, or by downloading and installing it directly from GitHub.

Overview

WSL container adds two new features to WSL: A built in Linux container CLI and an API for Windows applications to run Linux containers as part of their app logic.

WSL container CLI – wslc.exe

When you update to the latest WSL version, you will get a new binary on your path: wslc.exe. You can use this binary to do your full Linux container development workflows, including running, debugging, testing and more!

This CLI tool has a familiar format and capabilities, meaning you can use your existing muscle memory when running Linux containers. For example you can run a full Linux desktop in a container and connect to it like so: wslc run -d --name=webtop -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -p 3000:3000 -p 3001:3001 lscr.io/linuxserver/webtop:ubuntu-kde, or check your GPU access with a CUDA script: wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))". Lastly this also includes a built in alias for container.exe which just runs wslc.exe so you can use the container command or wslc, whichever you prefer.

WSL container API

Windows applications can now also directly use containers as part of their application logic. WSL now ships a Nuget package that is available at nuget.org and also on the WSL releases page. This includes support for C, C++ and C#.

Now your native Windows applications can make use of Linux for their production workflows. This can be especially useful for reusing existing Linux specific code, taking cloud applications and running them locally, or containing a Linux process’ access to resources on the host.

This API also integrates with MSBuild and CMake, so you can just add a few lines to your project files and the container build and deploy steps can all be part of your application’s build process – no manual steps required! Git clone and try a sample for yourself or check out the full API reference!

Learn more and see demos

You can view this presentation from BUILD 2026 to learn more about the use cases and see demos of these features in action. Additionally you can visit our docs page to get in depth guides and sample code.

Integration with enterprise tools

We are making sure that WSL’s great integration with enterprise tooling extends to WSL container as well.

Monitor security events in containers with Microsoft Defender for Endpoint (MDE)

WSL’s existing MDE plugin is updated to also be aware of Linux container events, providing you the same coverage whether you are using a WSL distro or containers. Currently this feature is available as part of a private preview which you can sign up for here.

Manage WSL container settings with Intune

We are also adding new management settings for WSL container. You will be able to control whether people can use WSL distros, or containers in your organization, and also specify an allowlist of which container registries can be used to pull new container images. One of our big aims for this area is to help address a top customer ask of: “How can I control which distros/Linux images are allowed in my organization?”, using WSL container and the registry allowlist makes that easier. This is available today using GPO and an ADMX policy and will have official support in Intune dashboards within the next few weeks.

VS code dev containers

Many enterprises also depend on tools like VS code dev containers, and WSLc support has been added in 0.462.0-pre-release. This is in pre-release right now but will soon be moving to general availability. To set up this functionality open the VS Code dev container settings, find the “Docker Path” setting and change that to be wslc.

Further WSL improvements

As we are building out the WSL container feature, we are also making huge improvements to the underlying technology that powers both WSL and WSL container. This includes:

• A new default file system for WSL container: ‘virtiofs’ that makes Windows file access 2x faster!
• A new default networking mode for WSL container: ‘consomme’ which aims to improve compatibility.
  • Compatibility is a tough issue since there are tons of different networking setups between VPNs, proxies and more. This is an experimental networking mode that aims to solve some of these issues. The simple explanation is that Consomme relays Linux network traffic through Windows allowing Linux applications to benefit from the same networking environment, security policies, and enterprise integrations available to Windows applications.
• Improved memory reclaim techniques to gradually and consistently release memory back to the Windows host when it’s not in use in the Linux VM

Since these changes touch mission critical paths like file system access and network, for now they are enabled just in WSL container and we are working towards enabling them in WSL by default in the future. There are also other fantastic Linux container CLI tools on Windows that build ontop of WSL like Docker Desktop, Podman Desktop and Rancher Desktop and these tools will also all benefit from these lower level platform changes so you can have a great selection of performant container tools on Windows that meet your needs.

Feedback and what’s next

This feature is currently only in the pre-release version of WSL as a public preview. Please install it and try it out, and as always you can file your issues and feedback at our GitHub page! We aim to make this feature generally available in the upcoming fall of 2026. Thank you for all the great support, and happy coding!

The post WSL container is now available for public preview appeared first on Windows Command Line.

---

Download audio: https://traffic.libsyn.com/secure/peopleandprojectspodcast/512-JuliaAndKristy.mp3?dest-id=107017