Clear the Git commits and history from the local & remote master repository

Introduction

Why would we clear the Git commits and history from the local & remote master repository? When preparing training labs leveraging Azure DevOps and Git, I often need to do a lot of testing and experimenting to empirically get the scenarios right. That means the commit history is cluttered with irrelevant commits for the lab training I am presenting.

Clearing the Git commits and history from the local & remote master repository
Photo by Gabriel Heinzer on Unsplash

Ideally, I reset the history to start a training lab when the repository is at the right stage. The students are then not bothered by the commits of previous demos. But how can we clear the Git commits and history from the local & remote master repository?

Clear the Git commits and history from the local & remote master repository

Git is meant to keep the commit history, as are repositories like Azure DevOps. That means there is no way to reset the commit history in Azure DevOps. Git, being a very powerful and, to a certain extent, also a dangerous tool, can help you overcome this. But how to do it is not always obvious. That said, you can also shoot yourself in the foot with Git, so pay attention and be careful.

Step 1 to Clear the Git commits and history from the local & remote master repository

If you keep branches around things get complicated. For my needs, I don’t need them. To delete a branch via git we need three (3) deletes.

git push origin --delete marshipdev
git branch --delete marshipdev
git branch --delete --remotes origin/marshipdev

The above lines respectively delete:

  • The remote branch in Azure DevOps
  • The local branch
  • The local remote tracking branch

You can also delete remote branches in Azure DevOps via the GUI by selecting a branch and selecting “Delete branch” in the menu. Locally you’ll need to use Git commands or the Git GUI.

Clear the Git commits and history from the local & remote master repository

Step 2

Create a new orphaned branch

git checkout --orphan myresetbranch

The Git option –orphan creates a branch that is in a git init “like” state. That is why we have an alternative option and that is to delete the .git folder in your local repository and run git init in it. That is why i normally keep a copy around of the “perfect” situation with the .git folder removed. I can copy that to create a new local master branch by running git init. I then have that track a new remote repository that still needs initializing via:

git remote add origin  https://[email protected]/workinghardinit/InfraAsCode/_git/AzureFwChildPolMarShip


git push --set-upstream origin master

But that is not what I am doing here, I am using another method.

Step 3

On your workstation in the local repository, make sure to clean and delete or edit and add all the files and folders we want to be in our master repository initial commit.

git add -A

git commit -m “Initial commit”

Note: we use -A here instead of  “.” Because we also want to delete any tracked files and folder that are currently being tracked. At the same time, it adds new items to be tracked. In practice it is like running both git -u and git .

Step 4

Now delete the current master branch

git branch -D master

Step 5

Rename the temporary branch to “master”

git branch -m master

We now have a master repository again locally.

Step 6

We now need to update the remote repository with the option –force or -f. That allows us to delete branches and tags as well as rewrite the history. Normally that is no allowed so we nee to temporarily allow this in Azure DevOps.

Clear the Git commits and history from the local & remote master repository

Now we can run

git push -f origin master

If we had not allowed Force push the above command would fail with an error indicating we need to allow “Force push”.
TF401027: You need the Git ‘ForcePush’ permission to perform this action.

Important: do not forget to set “Force push” back to “Not set”

Step 7 to Clear the Git commits and history from the local & remote master repository

Finally, make sure that the local master branch is set up to track origin/master.

git push --set-upstream origin master

That’s it, you now have a master repository in Azure DevOps that is ready to be cloned and used for labs with a clean commit history. Student can clone it, create branches, work on that repository and they will only see their changes and commit.

Conclusion

Resetting the git commit history of a repository is not a recommend action on production repositories under normal situations. But in situations like training lab repositories, it gives me a clean commit history to start my demos from.

Offline Azure Devops Windows 2012 R2 build server with failing builds

Introduction

While this post is about an Offline Azure Devops Windows 2012 R2 build server with failing builds let me talk about the depreciation of TLS 1.0/1.1. Now this is just my humble opinion, as someone who has been implementing TLS 1.3, QUIC and even SMB over QUIC. The out phasing of TLS 1.0/1.1 in favor of TLS 1.2 has been an effort done at snail’s pace. But hey, here we are,  TLS 1.0/1.1 are still working for Azure Devops Services. Many years after all the talk, hints, tips, hunches and efforts to get rid of it. They did disable it finally on November 31st 2021 (Deprecating weak cryptographic standards (TLS 1.0 and TLS 1.1) in Azure DevOps)) but on January 31st 2022 Microsoft had to re-enable it since to many customers ran into issues. Sigh.

Tech Debt

The biggest reason for these issues are tech debt, i.e. old server versions. So it was in this case, but with a twist. Why was the build server still running Windows Server 2012 R2? Well in this case the developers won’t allow an upgrade or migration of the server to a newer version because they are scared they won’t be able to get the configuration running again and won’t be able to build their code anymore. This is not a joke but better to laugh than to cry, that place has chased away most good developers long ago and left pretty few willing to fight the good fight as there no reward for doing the right things, quite the opposite.

Offline Azure Devops Windows 2012 R2 build server with failing builds

But Microsoft, rightly so, must disable TLS 1.0/1.1 and will do so on March 31st 2022. To enable customers to detect issues they enabled it already temporarily on March 22nd (https://orgname.visualstudio.com)and 24th (https://dev.azure.com/orgname) form 09:00 to 21:00 UTC.

Guess what? On March 24th I got a call to trouble shoot Azure Devops Services build server issues. A certain critical on-premises build server shows as off line in Azure and their builds with a dead line of March 25th were failing. Who you going to call?

Offline Azure Devops Windows 2012 R2 build server with failing builds
No bueno!

That’s right, WorkingHardInIT! Sure enough, a quick test (Invoke-WebRequest -Uri status.dev.azure.com -UseBasicParsing).StatusDescription did not return OK.

Now what made it interesting is that this Windows Server 2012R2 had been setup so that it would only support TLS 1.2 some years ago because they has issues with chipper mismatches and SQL Server (see Intermittent TLS issues with Windows Server 2012 R2 connecting to SQL Server 2016 running on Windows Server 2016 or 2019). So why was it failing and why did it not fail before?

Windows Server 2012 R2 with Azure Devops Services from March 31st 2022

To run Windows Server 2012 R2 with Azure Devops Services from March 31st 2022 there are some requirements listed in Deprecating weak cryptographic standards (TLS 1.0 and 1.1) in Azure DevOps Services.

Well first of all that server only had .NET 4.6 installed. .NET 4.7 or higher is a requirement after March 31st 2022 for connectivity to Azure Devops Services.

So, I checked that there were (working backups) and made a Hyper-V checkpoint of the VM. I then installed .NET 4.8 and rebooted the host. I ran (Invoke-WebRequest -Uri status.dev.azure.com -UseBasicParsing).StatusDescription again, but no joy.

There is another requirement that you must pay extra attention to, the enable ciphers! Specifically for Windows Server 2012 R2 the below cipher suites are the only two that will work with Azure Devops Services.

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

On that old build server they were missing. Why? We enforced TLS 1.2 only a few years back but the PowerShell script  used to do so did not enable these chippers. The code itself is fine. You can find it at Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2 | Hass – IT Consulting.

But pay attention to the part about the AEAD ciphers that are only available on Windows Server 2012 R2. The above to ciphers are missing and I added them.

Offline Azure Devops Windows 2012 R2 build server with failing builds
Add the two ciphers needed for W2K12R2 with Azure Devops

Add those two ciphers to the part for Windows Server 2012 R2. and run the script again. That requires a server reboot.Our check with (Invoke-WebRequest -Uri status.dev.azure.com -UseBasicParsing).StatusDescription returns OK. The build server was online again in Azure Devops and they could build whatever they want via Azure Devops.

Conclusion

Tech debt is all around us. I avoid it as much as possible. Now, on this occurrence I was able to fix the issue quite easily. But I walked away telling them to either move the builds to azure or replace the VM with Windows Server 2022 (they won’t). There are reasons such a cost, consistent build speed to stay with an on-prem virtual machine. But than one should keep it in tip top shape. The situation that no one dares touch it is disconcerting. And in the end, I come in and do touch it, minimally, for them to be able to work. Touching tech is unavoidable, from monthly patching, over software upgrades to operating system upgrades. Someone needs to do this. Either you take that responsibility or you let someone (Azure) do that for you.