The art of simplicity

Yesterday I was talking about git submodule support in Visual Studio and that reminded me of something else: Azure DevOps Server got submodule support too. It's a small feature, but a genuinely useful one. Why do we need this? If you've worked with submodules before, you know the annoying part isn't adding them, it's navigating them afterwards. In the Files hub, a submodule used to just show up as a folder reference. To actually browse its content, you had to know the submodule's repo, open it separately, and find the right commit yourself. What changed Azure DevOps Server now has UI support for Git submodules in the Files hub. You can click straight into a submodule from your project and land exactly on the commit that's referenced there. No more manually tracking down the right repo and commit by hand. It works across multiple Git services that a submodule can point to: Azure Repos GitHub GitLab Bitbucket Multiple .gitmodules URL...

Git submodules wasn't a feature I used that often. Until we started to use it as a way to share context( agent.md ) and skills between our projects. That's the moment we discovered that Git submodule support was missing in Visual Studio and we had to fall back to the terminal typing git submodule update --init --recursive With Visual Studio 18.9, that finally changes. Submodules are now a first-class part of the Git experience in the IDE. What was missing Submodules are genuinely useful. They let you pull a shared library, an SDK, or a set of build scripts into your repository without copy-pasting code around. You could fall back to the command line, but the tooling was missing. Visual Studio would show you a submodule as a plain folder, with no indication of its state, no way to add or remove one from the UI, and no understanding of how it related to the parent repository. Every actual submodule operation meant tabbing out to the command line. What you get now Open a...

There's a moment when you clone or pull a repository on Windows and Git throws an error like this: error: unable to create file some/very/deeply/nested/path/to/a/file.ts: Filename too long Nothing wrong with your code, nothing wrong with the repo. It's Windows. Why does this happen? Windows has a default path length limitation of 260 characters (the infamous MAX_PATH ). Git operations that create files with a full path longer than that — cloning, checking out, pulling — will fail with this error. Repositories with deeply nested folder structures (think node_modules, or generated code) hit this constantly. The fix: enable long paths in Git Git has a config setting for exactly this: core.longpaths . You have two ways to set it, depending on your rights on the machine. System-wide (requires Administrator privileges): git config --system core.longpaths true User-level (no Administrator required): git config --global core.longpaths true If y...

After a routine Visual Studio update silently upgraded Git for Windows to version 2.49.0, pushes to Azure DevOps started failing with a cryptic NTLM authentication error — even though our setup was supposed to use Kerberos. Here's what happened and how to fix it in 30 seconds. The symptoms You update Visual Studio (or Git for Windows directly), and suddenly any push to your Azure DevOps remote fails. The error mentions NTLM even though your network is configured for Kerberos. Typical signs: Git push fails immediately after a Visual Studio or Git for Windows update Error references NTLM authentication failure Clones and fetches from the same remote may still work The remote URL is an internal TFS/Azure DevOps server (e.g. https://tfs.yourcompany.com ) What changed Git for Windows 2.49.0 (shipped as MinGit 2.49.0) changed how it negotiates authentication for HTTPS remotes. The new default behaviour causes Git to attempt NTLM where it previously fell through ...

I mostly use the built-in functionality to set a tag on a specific commit after a successful release. However, in this case I was contacted by a colleague who was using the Git Tag task . Unfortunately, he couldn’t get the task working. A look at the build log made it obvious what the problem was: Starting: GitTag ============================================================================== Task         : Git Tag Description  : A simple task that tags a commit Version      : 7.0.0 Author       : ATP P&I IT Help         : tags the current commit with a specified tag. ### Prerequisites * Repository must be VSTS Git. * Allow scripts to access Oauth must be **Enabled** * Project Collection Build Service must have **Contribute** & **Create Tag** set to **Allow** or **Inherit Allow** for that particular repository =======...

If you're working with Git repositories in Visual Studio Code, you might occasionally need to checkout a specific tag—perhaps to review a previous release, test an older version, or understand how the codebase looked at a particular milestone. While VSCode's built-in Git integration is powerful, checking out tags wasn't immediately obvious to me. Let me walk you through the process. What are Git tags? Before diving in, a quick refresher: Git tags are references that point to specific commits in your repository's history. They're commonly used to mark release points (like v1.0.0, v2.1.3, etc.). Unlike branches, tags are meant to be immutable snapshots of your code at a particular moment in time. Checkout a Git tag in VS Code Method 1: Using the Command Palette The quickest way to checkout a tag in VSCode is through the Command Palette: Open the Command Palette by pressing Ctrl+Shift+P (Windows/Linux) or Cmd+Shift+P (Mac) Type "Git: Checko...

Azure DevOps offers a repository health feature, which allows to monitor multiple metrics that contribute to the health of your Git repositories. If you are using Azure DevOps services, you maybe already know this feature. But with the latest release of Azure DevOps server (December 2025) , it finally arrived on-premise as well. Reasons enough to have a deeper look at it and write this post. Let’s dive in! Why is this feature relevant for my team? Think of your Git repository like a living organism. As it grows with more commits, blobs, branches, and objects, it can become sluggish and unwieldy. Large repositories increase the load on Azure DevOps infrastructure, affecting performance and user experience. Without proper maintenance, your team could face slower clone times, degraded git operations, and even service disruptions. The repository health feature now provides visibility into key health metrics and offers actionable recommendations before problems escalate. Getting t...

A while ago I blogged about how we could setup our own multi-agent workflow by using Git worktrees. With Git worktrees you can setup a branch as a separate folder. If you combine this with the GitHub Copilot CLI you could have multiple agents all working simultaneously on multiple branches while you can continue development as well. Although the process I described works quite well, it remained somewhat cumbersome and was not well integrated into the VSCode development experience. Not anymore with background agents… The problem with foreground-only agents By defaullt, the Copilot agent operates in the foreground. When you ask Copilot to refactor a function or write tests, you're essentially blocked until the task completes. Your editor is locked into that conversation, that context, that task. This works fine for quick queries, but what about: Running comprehensive test suites while you continue development Refactoring an entire module while you work on a new featu...

Have you ever wanted to see your project's Git history come to life? Gource is a fantastic tool that transforms your commit history into a mesmerizing animated visualization, showing how your codebase grows and evolves over time. It's like watching a time-lapse of your project's development, with files appearing, changing, and moving as contributors work on different parts of the code. But Gource is more than just eye candy. I like to use this tool to spot architectural patterns, identify hotspots where code changes frequently, understand how the team collaborates, and even detect potential coupling issues before they become problems. It's a powerful lens for understanding not just what a team has built, but how they've built it. In this post, I'll walk you through everything you need to know to create your first Gource visualization and use it to gain valuable insights into your codebase's architecture. What is Gource? Gource is an open-source vis...

As AI coding assistants become more sophisticated, we're approaching a future where multiple agents might work on different parts of your codebase simultaneously. But there's a challenge: how do you let multiple processes work on the same repository without constantly stepping on each other's toes? One solution is to have agents work on dedicated machines like GitHub Copilot Agent does in a GitHub Codespace. But what if you want to have multiple agents working on your local machine? Enter git worktrees – a powerful Git feature that's been hiding in plain sight since 2015, and the perfect foundation for multi-agent development workflows. What are Git worktrees? Git worktrees allow you to check out multiple branches from the same repository simultaneously, each in its own directory. Think of it as having multiple working directories all sharing the same Git history, but each can be on a different branch. Here's the key insight: while the working directories...

When working with Azure DevOps repositories, Personal Access Tokens (PATs) offer an alternative to traditional authentication. Although I would not recommend them for general usage, there are some scenario's where a PAT is a secure option providing security through scoped permissions, expiration dates, and the ability to revoke access without changing your primary credentials. I had a situation where I needed to clone a set of GIT repositories and run a scan on each repository. As the script would be running for a long time I thought it would be better to create and use a PAT instead of my own account. Creating a Personal Access Token (PAT) Sign in to your Azure DevOps organization Click on your profile icon in the top right corner Select "Personal access tokens" Click "+ New Token" Configure your token: Give it a meaningful name Set an expiration date Select the organization Under "Scopes," ...

For security reasons I am switching to a different account on my development machine. After adding this new account to Windows and setting up the Visual Studio configuration for this new account, I thought I was good to go. So I opened a first solution inside my fresh Visual Studio instance. Everything looked OK at first sight, but then I noticed a small warning message at the right bottom corner of my Visual Studio: And when I took a look at the Git Changes window, no changes were shown:   What is going on? Starting from Git v2.35.2 , Git now checks for ownership of the folder trying to ensure that the folder you are using Git in has the same user as the owner as your current user account. As the original Git repo(and corresponding Windows folders) was created using a different account, Git considers this repository as unsafe. This check was introduced in Git to tackle a security issue which allows parent repositories directories to override permissions of child reposi...

While working in Visual Studio today I noticed a message appear at the top my idea. The message stated the following: Speed up your git experience in Visual Studio by enabling the git commit graph algorithm. No idea what that exactly means but that sounds promising… so let’s find out Why this commit graph algorithm? Git repositories can become sluggish as they grow in size and complexity. If you've ever waited impatiently for git log to load or noticed that branch operations take longer than they should, you're not alone. Recently, Git introduced a powerful feature that can dramatically improve performance: the commit graph algorithm. The commit graph is a data structure that Git uses to store precomputed information about your repository's commit history. Instead of traversing the entire commit tree every time you run commands like git log , git merge-base , or git show-branch , Git can use this precomputed graph to answer queries much faster. Think of it ...

Git is my 'go-to' version control tool for a long time. I switched from SVN & TFVS (Team Foundation Version Control) a long time ago and never looked back. One feature that I used sometimes in TFVC was the cherry-pick feature but since I started using GIT I never used cherry-pick anymore. Until today... What is cherry-picking? Cherry-picking refers to the process of selecting a specific, individual commit from one branch and applying it to another. Unlike merging or rebasing entire branches, cherry-picking lets you choose exactly which changes you want to incorporate. Think of it as picking cherries from a tree (hence the name): instead of harvesting all the fruit, you carefully select only the ripest, most desirable ones. When to use cherry-picking? I have some bad memories from using cherry-picking in TFVC as it was used a lot as a poor mans alternative to a good versioning strategy. But there are some scenarios where cherry-picking can be useful: Backpor...

Being new to Github I decided to write a few post on how to create a new 'release' in Github. I'll start with a 100% manual approach(this post) and will continue with other posts showing a more and more automated process. But today we'll start simple and focus on creating a release by hand. This allows me to introduce the different elements that we can configure when using releases inside Github, knowledge that will be useful later when we go the automated route. Let’s dive in… Creating a new release (manually) Before you can create a release, make sure you are signed in to your GitHub account. Navigate to the repository where you want to create the release. Once you’re in the repository, click on Releases on the right of the list of files.   On the Releases page, you’ll see a button labeled “ Draft a new release .” Click on it to start creating your new release.   The first thing you need to do is to assign a tag to your release. A tag is usuall...