Hide contents of git repository from subcontractors

Question

I have an application that has a lot of UI, DB, ... and also a background processing part. I want to keep the background processing part hidden from my contractors so they can't disclose the clever algorithm I came up with.

What's the right way to do that with git?

I started out with submodules: I have the main repo with all the UI, DB, ... in there and a secret repo which I included via a git submodule. After I change stuff in the processing part of the app, I minify it (it's JS), and save it to the main repo, so it can be used by the rest of the application. This way the contractor can pull my minified file as part of the main repo. Then run the app without the need for the secret code. So far so good.

However, the problems are:

1. The contractor gets errors when checking out the main project because the submodule is not accessible for him
2. The contractor has accidentally created a "remove processing submodule" commit, because the submodule folder is not there, and if he does git add . and then commits, git assumes that he wanted to delete the submodule.

So all in all it seems that's not the right strategy. I read that git subtree can be used, but I didn't find any example on how to use it for that use case.

Any help is highly appreciated!

Answer 1

1. The contractor gets errors when checking out the main project because the submodule is not accessible for him

That's not really an error, submodules are separate histories because they're separate histories, if you don't need one of the pieces just don't init/update it, and the contractor doesn't need it. --init --recursive is a common git submodule update option set, but there's a reason they're options. This is why.

2. The contractor has accidentally created a "remove processing submodule" commit, because the submodule folder is not there, and if he does git add . and then commits, git assumes that he wanted to delete the submodule.

Yes, this is a downside of Git switching git add to default to also implicitly tracking removal in the 2.0 transition. One way to stop this happening in the future is for the contractor to enable sparse checkout and include everything except that submodule, git sparse-checkout set '*' '!that/submodule', or they could do it manually as a one-off with git update-index --skip-worktree that/submodule; or you could do one of your mergebacks --no-commit and I think git checkout --ours that/submodule would restore the index entry before committing the merge, from then on Git will see no change on the contractor's history so it won't conflict with anything you do.

---

Another way to manage this is to keep public and private histories as in this answer where you --amend the public commit to not include the content you want concealed, and do all future updates from private to public with similarly-edited squash merges followed by a -s ours mergeback as shown there.

Answer 2

You can try the other way around :

• have the public part in a self contained repo,
• include that public part as a submodule in a bigger, private repo that has the complete source code.

When you build the source code ("building" is minifying if I understand correctly), you just have to place the output of the build in the subrepo part.