MAB Labs has been recently working a project where we’ve needed to work on different branches of the same git repository. However, creating multiple clones of the same remote repository have caused some issues in our workflow. To avoid these issues, we instead created a single local clone of the remote repository, and created copies of the local clone. This procedure effectively creates a new “local remote”, on which the clones are based off. Read below to see why and how we did this.
You may wonder why we weren’t following the typical git workflow, which usually involves working on a branch, making sure we’re happy with the changes in the branch, committing our changes, and moving to another branch.
While this may be the appropriate workflow for most projects, MAB Labs was working on an FPGA-based project where the build times were on the order of hours. Since we didn’t want to wait for the build to complete before testing it on the final hardware (we confirmed the feature in simulation) and moving to another branch, we couldn’t follow the git workflow outlined above. We also wanted to preserve the build artifacts to review the timing and resource utilization reports of the build, which are critical in any FPGA design.
These reasons required multiple copies of the same repository. However, having multiple clones of the same repository causes two issues. First, it takes time to clone the remote repository, and depending on the size of our repository and network configuration, that time may be substantial. Second, if we want to merge branches across different directories, we would have to push the change in one directory, pull the branch in another directory, and perform the merge.
However, we can have a single clone of the remote repository and can create separate clones of our “local remote” repository. This way, we avoid spending time constantly pulling from and pushing to the remote repository if we’re working on multiple branches. We could push from our local clones to our “local remote”, manage branch operations on our “local remote” repository, and then push up to our actual remote repository.
Creating this structure is not difficult. First, we need to create a clone of the remote repository, which will serve as our new “local remote” repository:
git clone <repository url> <local remote path>
Where the “repository url” is the URL of the remote repository and “local remote path” is the name of the directory to clone the repo into (if not specified, this is identical to the name of the repository).
Then, we can simply clone the cloned repository (our “local remote”):
git clone <local remote path> <locally cloned path>
In the above snippet, “locally cloned path” must be provided. Otherwise, git will complain that a repository of the same name already exists. When we run the above command, we notice that it executed much more quickly than the previous command. This is because our “local remote” is locally present and there is no need for git to reach out to the server where the repository is located.
And that’s it! We can create as many local copies of the clone of the remote repository. The only limiting factor is the size of the repository and the free space available on our hard drive.