Configuring Git Remotes: Fetch Only One Branch and No Tags

26 January 2026 by Phillip Johnston

Burnout has kept me away from several different projects for years. I’ve forgotten completely about some problems, the tools have changed underneath me, or both.

In any case, I’m looking at my monorepo setup with fresh eyes. I noticed several things that bother me:

• Setup takes a while, with a lot of time spent in fetch operations, because…
• Git is fetching branches from the remotes that aren’t actually needed
• Git is fetching tags from remotes, and because many of these are version numbers, there’s a ton of rejection notices

From https://github.com/embeddedartistry/libmemory
 * [new branch]          master        -> libmemory/master
 * [new branch]          pj/asan       -> libmemory/pj/asan
 * [new branch]          pj/build      -> libmemory/pj/build
   [...]
 * [new tag]             0.1.8         -> 0.1.8
 ! [rejected]            1.0.10        -> 1.0.10  (would clobber existing tag)
 ! [rejected]            1.0.11        -> 1.0.11  (would clobber existing tag)
 ! [rejected]            1.0.12        -> 1.0.12  (would clobber existing tag)

As a refresher, in the monorepo model we’re using, we still push out updates to the many existing standalone repositories from within the monorepo. All we require from the remote is the primary branch for our monorepo (main/master). All the remotes are stored in .gitconfig, and we can get the behavior we want with a few changes.

1. Remove wildcarding from the fetch spec, specifying only the branches we want
2. Add tagOpt = --no-tags
3. Add another fetch spec that excludes all tags.

[remote"cmake"]
    url = https://github.com/embeddedartistry/cmake-buildsystem
    fetch = +refs/heads/main:refs/remotes/cmake/main
    tagOpt = --no-tags
    fetch = ^refs/tags/*

The last part is important. I thought that tagOpt = --no-tags would be needed in order to mirror the behavior of git fetch --no-tags. But, without the final fetch spec, git was still retrieving all the tags.

This did the trick, and now setting up a newly cloned monorepo instance is much faster AND far less noisy than before.

References

• Monorepo Development
• An Experiment: Develop in a Monorepo and Distribute to Standalone Repositories – outlines why we decided to create a monorepo, and why we will keep pushing changes to distributed repositories for consumption