Sometimes the hardest part of contributing to a Terraform provider is not the resource implementation itself, but figuring out how to collaborate when the repository topology gets complicated. That is exactly the situation here. A colleague has forked the AzureRM provider and started adding support for the Azure AI Search data plane SDK, which opens the door to a much broader and more exciting set of resources. I want to build on top of that work and add the resources I care about most. The catch is that I had already forked the original AzureRM provider from HashiCorp, so I cannot create a second GitHub fork of my colleague’s repository. Instead, I need to treat their fork as an additional remote in my existing local clone and work from there.

Starting Point

My local clone was already set up in the standard way, with my fork as origin and the official HashiCorp repository as upstream. Running git remote -v showed the remotes I already had configured:

git remote -v

This tells me the remotes there are on my local cloned repo.

I already have the hashicorp upstream.

origin  git@github.com:markti/terraform-provider-azurerm.git (fetch)
origin  git@github.com:markti/terraform-provider-azurerm.git (push)
upstream        https://github.com/hashicorp/terraform-provider-azurerm.git (fetch)
upstream        https://github.com/hashicorp/terraform-provider-azurerm.git (push)

That part was familiar. My fork points to my own GitHub repository, and upstream points to the original Terraform AzureRM provider maintained by HashiCorp. I had also already been doing work in this repository on a local branch named origin/feature/markti/issue31530, which I used to fix an issue related to Azure Container Apps. So this was not a fresh clone or a clean sandbox. It was an active working repository with existing remotes and feature branches.

The Problem With GitHub Forks

The complication came from wanting to contribute on top of another developer’s fork rather than directly on top of the HashiCorp upstream. That developer had started a substantial piece of work: integrating the Azure AI Search data plane SDK into the provider. This is a large addition, and it is exactly the foundation I need for the resources I want to add. In particular, I want to add support for creating and managing Azure AI Search indices with Terraform. Right now I am doing that with Terracurl, and it is frankly terrible. The whole point of this effort is to get to a cleaner, first-class provider experience.

GitHub only allows a repository to be forked once per account from a given upstream, so I could not create another fork relationship for my colleague’s repository. That meant the solution had to happen locally in Git rather than through GitHub’s fork UI.

Adding a Second Upstream-Like Remote

The answer was to add my colleague’s repository as another remote. In my case, I added it under the name qixialu:

git remote add qixialu git@github.com:QixiaLu/terraform-provider-azurerm.git
git fetch qixialu

After that, git remote -v showed all three remotes:

origin  git@github.com:markti/terraform-provider-azurerm.git (fetch)
origin  git@github.com:markti/terraform-provider-azurerm.git (push)
qixialu git@github.com:QixiaLu/terraform-provider-azurerm.git (fetch)
qixialu git@github.com:QixiaLu/terraform-provider-azurerm.git (push)
upstream        https://github.com/hashicorp/terraform-provider-azurerm.git (fetch)
upstream        https://github.com/hashicorp/terraform-provider-azurerm.git (push)

At that point, the repository layout made sense again. origin remained my personal fork, upstream remained the official HashiCorp source, and qixialu became the collaborator remote containing the Azure AI Search data plane work I want to build on. Even though GitHub does not let me formally fork that repository, Git itself does not care. As long as the remote is configured, I can fetch branches from it and create my own work on top of them.

Targeting the Right Branch

The branch I care about in that remote is ai-search-datasources. That is where the exciting work lives. Rather than starting from the default HashiCorp branch and redoing everything manually, I can base my own feature work directly on the branch that already contains the Azure AI Search data plane SDK integration.

The branch that I want is ai-search-datasources . Very exciting.

I opened a new branch called feature/search-index because I want to add the ability to create and manage Azure AI Search indices using Terraform. I am currently doing this with terracurl and it is god awful.

Building on the Existing Search Work

Once I started looking through the code, I noticed that the other developer had already added a new data source for a Blob resource under the services/search directory. That is an encouraging sign because it shows where this functionality is intended to live in the provider structure. It also confirms that the search-related data plane work is being organized in a way that matches the provider’s existing service layout.

That directory appears to be the right place for the resources I want to add. Since the Blob resource data source is already there, it provides both a technical anchor and a style reference. I can use it to understand how the new SDK has been wired into the provider, how clients are initialized, how schema and CRUD logic are being structured, and how acceptance tests or supporting helpers are expected to fit into the codebase.

This matters because the biggest change here is not just “adding another resource.” The real shift is that the provider is beginning to support Azure AI Search through the data plane SDK, and that changes what kinds of Terraform resources become possible. Once that foundation exists, managing search indices directly in Terraform becomes much more natural than trying to force the same workflow through Terracurl.

The big change is the inclusion of the Azure AI Search Data Plane SDK.

I see that the other developer added a new data source for a Blob Resource in the services/search directory. This seems like the right place for me to add new resources that I want.

Evolving From a Workaround to a Real Provider Resource

Before this, I had been managing Azure AI Search indices with Terracurl. It worked in the narrowest possible sense, but it was unpleasant and brittle. It never felt like a real provider solution. Every time I had to model index creation that way, it reinforced the same conclusion: this should be a proper Terraform resource backed by provider code, schema validation, lifecycle handling, and all the normal ergonomics users expect.

That is why this fork-on-top-of-a-fork situation is worth solving correctly. The Git setup is just the enabling step. The real value is being able to contribute directly to the branch that already introduced the Azure AI Search data plane SDK, and then layer search index resources on top of that implementation. Instead of working around the provider, I can help extend it.

Conclusion

In the end, the solution to “forking a fork” is not to fight GitHub’s limitations, but to use Git remotes deliberately. My repository now has three important remotes: my fork as origin, the HashiCorp repository as upstream, and my colleague’s fork as qixialu. That setup lets me fetch the ai-search-datasources branch, create my own feature/search-index branch from it, and begin adding the Azure AI Search index resources I need.

What started as a repository management problem quickly became the first step toward a much better Terraform experience. The Azure AI Search data plane SDK is the major enabling change, and the work already present in services/search shows the path forward. With that structure in place, I can stop relying on Terracurl for index management and start building the provider support that should have existed all along.