Correct way to maintain offline repos

This is the setup, we have 2 areas a open area and a restricted area. the 2 networks are completely disconnected. We do most of the development in the open, however, there are things that both overlap and are unique in the restricted area.

Currently the restricted area is updated by copying over a checkout of the master branch, then using some diff tool to copy the changes, then check in. doing it this way means that the history is lost, as are the many other branches. To add to the mix, we do use subtrees in our open repo to separate certain modules., but that method wouldnt really work in the restricted area, as there is overlap

I can be certain that this isn’t the correct way to do this, but I’m not really sure what the best way to use git to make this happen.

Thanks, Austin

Welcome to the GitLab forums @raceratb :slight_smile:

I’m not sure that I can help with the subtrees part of your question much, but about the checkout: Is that definitely required from some other reason than transferring the data?

Git has several history-preserving commands that could be useful to you command: format-patch, apply or am to import changesets into a /home-folder-based clone of the GitLab repo on that same, air-gapped server (per branch, I think).

Maybe archive or bundle could also be useful to you, unless the repo is quite large already.

I hope this helps you already! I’ll ask around internally for a subtree veteran :wink:


It’s not so much a subtree question, it’s more of what it the best way to handle these 2 environments, and propagating the open changes to the restricted side. Subtree was just an additional consideration. We tried doing a git pull <path to .git folder>, but had many merge conflicts. Conflicts that looked like white space. If we just need to resolve those, and then going forward the process will be smoother than that’s ok. But using something like beyond compare to only bring over the branch updates misses all the history.

The desire is to get on the correct path, and not repeat past mistakes.

Format patch does seem like a good solution to bring thing back out, as only text is allowed to go the other way. This data path is very rare and heavily restricted.

Yeah, resolving the conflicts in either of the repositories and then using a git-based method to transfer changes from then on is what I would recommend.

About the air-gap: I didn’t find a better alternative internally, than those the world has already found :wink:

Please let me know if you have any other questions. Cheers!

1 Like

Thanks, my Google-fu was not up to this specific question. Air gap was exactly what I was looking for. :wink: