My disk was full the other day, so I needed to clean up. First the obvious stuff, like the Downloads-folder, the Nuget-cache, the bin- & obj-folders and the Temp-directory. Second, I used WinDirStat to figure out where the other biggest culprits of data-usage are to be found.

One of the directories was the main project I’m working on, with a staggering 24GB in disk size! Obviously, we’ve created a lot of code in the past years, but not THAT much.

The cause of this, is at some point in time we committed a large file in the repository and it got a couple of revisions over time. Of course, we all know we should not commit large files in a Git repository and there are better solutions (Git LFS), but real-world happens.

What not to do

In short, don’t nuke the file from your repository.
This messes up a lot of stuff for the other contributors. While it might be the best solution, it will break other peoples workflow. But if you don’t mind this, or are the single contributor, feel free to play around with the suggestions shared over here: https://www.baeldung.com/ops/git-remove-file-commit-history

A request came by me to:

Get all the commits associated to a specific release, based on the previous succesful release.

The fun thing is, we’re using Azure DevOps.
Easy right?

Well, that’s what I thought, because this information is readily available in the web interface of Azure DevOps.

As the saying goes:

We do things not because it is easy, but because we thought it would be easy!

This phrase applies to the above request.

When starting out, I figured there must be some environment variable, or endpoint I can invoke to get these details. On the command-line, this is pretty git log command. Turns out, there isn’t. I did ask on Stack Overflow, but it appears the only way to get this data is to invoke several Azure DevOps REST API endpoints.
Not a big problem, but surely more work as expected.

Because of my earlier investigations on integrating with Azure DevOps, I was aware of the REST API service & documentation that is provided on the topic.

The initial implementation

With the documentation available I kind of knew the /_apis/release/releases would be my starting point.
From with the response of this endpoint you should be able to identify the current, and previous releases. In my case, I want to get the previous succesful release that had a specific stage in a succesful state. Quite possible with the response that you get.
Now that you know the previous release identifier, the changes endpoint can be invoked, taking the release id of the current and previous run.

It so happens a lot of people are mixing their work- and personal development machines, especially when doing side projects in their spare time which are somewhat work-related.
At least, this is the case for me as I’m using GitHub both for work & personal stuff nowadays.

On my personal machine, I’ve set up Git to work with my personal e-mail address & SSH keys.
On my work machine, I’ve set it up to run with my work account.
Because of this, whenever I commit a change this configured account will be used and I don’t want my corporate account to show up in my side projects, and vice-versa.

Lucky for me, there are a couple of people on Stack Overflow who have similar setups and were also wondering how to fix this. I’m quite happy with the answers posted to Kevin Whitaker’s question.

There are answers on how to do this with SSH keys, which is probably the best option.

However, most repositories on my machine are set up with HTTPS, so the answer from Greg Leszek is the best for my scenario.

He mentions that you first have to change the origin URL to have your username in the URI if this isn’t the case already.
Afterward, you can set the user details you need to use for this repository.

With the new Windows Terminal available I’ve been searching on how to upgrade my console experience. I see a lot of people improving their terminal to show important information, like which Git branch you are working on, which Azure subscription, the actual location on disk, etc.

A couple of months ago I came across Brad Wilson his post on the matter and I like the way his terminal looks. His post, is rather straightforward, but there was some information missing. Well, ‘missing’ isn’t the correct word. In his post he has assumed some prerequisites which I hadn’t set up on my machine(s).

For reference sake, I’ll repeat some steps over here from Brad his post and add some of myself which were unclear to me.

First of all, you need to install posh-git. This is a small PowerShell module which integrates Git in PowerShell. It’s very useful and now that I know of it I advise everyone to use it!

I did have some versioning issues when installing this though. The first time when I ran the command PS> install-module posh-git I got the following message(s).

PowerShellGet requires NuGet provider version '2.8.5.201' or newer to interact with NuGet-based repositories. The NuGet provider must be available in 'C:\Program Files\PackageManagement\ProviderAssemblies' or 'C:\Users\jan\AppData\Local\PackageManagement\ProviderAssemblies'. You can also install the NuGet provider by running 'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'. Do you want PowerShellGet to install and import the NuGet provider now?

[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y

Untrusted repository

You are installing the modules from an untrusted repository. If you trust this repository, change its InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from 'PSGallery'?

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"):

Eventually, I was able to get this to work, but I had to update my PowerShellGet repository first. As you can see from the script below, this also failed.

The past couple of days I’ve had the pleasure to start using a Git server as the new version control system at my customer. I’ve already had the pleasure to use GitHub and BitBucket in the past, which works like a charm with tools like GitHub for Windows and SourceTree. Because I’m used to using these tools, I really wanted to use them on my day job also.

Because we chose to use SSH keys as a validation mechanism I had to create one. Once you know how to do this it’s quite easy, but till 2 days ago I didn’t had a clue.

Lucky for me there’s a nice tutorial on how to create SSH keys on the GitHub help pages. Also Atlassian has provided an extensive help document with a couple of steps. In retrospect I think the Atlassian help page is the most useful for helping out with local Git servers. However, these help documents don’t take into account the usage of SourceTree and you will need to do some extra steps to get this working.

For future reference, I’ll describe the steps I had to take below.

First thing you want to do is install Git, the Git Extensions and if you haven’t already, SourceTree.