Problem and Motivation
We have a larger git repository on our central server. There is a lot of history in it that we want to keep, so rebasing or squashing anything there is not really an option. However, when cloning the repository to our development servers, only recent history is actually relevant. For us, "recent" can be defined as a given tag and any commit earlier in the history can be omitted. The aim here is to save bandwidth, time and disk space.
Ideas for Approach
The current idea is to clone that tag only, using git clone --branch my-root-tag --depth 1
, treating it as an artificial root commit in that local repository. Afterwards, adding branches that we'd like to fetch manually using git remote set-branches --add origin some-branch
. All of these branches must include my-root-tag
somewhere in their history. However, every fetch would now again transfer the entire history. Is there any way to restrict fetches to stop at my-root-tag
instead? It sounds like this approach would need something like asked in git shallow clone since specific commit, ideally wrapped in a git alias to "dynamically" calculate the value of the --depth
parameter.
Can anyone think of a way to get this to work or even by applying some entirely different approach?
Results
edit: To summarize, it seems that a git fetch
does indeed only transfer the commits up to the grafted new repository root (at least in Git v 2.25.1). Only the original clone
needs to be parameterized correctly, while subsequent operations on the repository can be performed using regular (unparameterized) git commands. No shallow-include
or shallow-exclude
options are actually necessary now. This is great news as it makes that configuration a lot less fragile than initially feared.