I have a repository for a project that contains both an executable and a library.

My repo

I am now working with a company that wants to use my library in their project as well. They want to vendor (i.e., make a one-time copy of) a subset of my repository in their repository.

Their repo

They won't use a submodule or clone my repository during build time. They want a separate copy of my code. I will likely be the one managing both sets of source code.

My questions is: Is there a clean way to automatically keep the two sets of code in sync so that I can manage any future changes from a single repository?

  • 2
    Isn't this their problem, not yours?
    – jonrsharpe
    Commented Feb 8, 2017 at 19:25
  • 1
    If it's a one-time copy, why do you need to maintain anything? Is one repo just a subtree of the other? Is the executable built from the same source? Etc.
    – jonrsharpe
    Commented Feb 8, 2017 at 19:36
  • 1
    Your project should have separate repos for your library and your executable. Their project should fork your library repo and have a separate repo for their executable. Commented Feb 8, 2017 at 20:40
  • 4
    Forking would give them direct control over their dependencies. Maybe they don't understand that. Commented Feb 8, 2017 at 21:07
  • 1
    More so than relying on you to keep maintaining whatever structure they need. That's not the best thing for either party.
    – jonrsharpe
    Commented Feb 8, 2017 at 21:33

2 Answers 2


A possible solution might be the git subtree command. In the companies repo: First add your repository (or alternatively a local fork) as remote (not strictly necessary, but simplifies stuff a bit)

git remote add lib https://myurl

Then check out your code with an appropriate prefix:

git subtree add --prefix vendor/src/my-lib lib master

(You can also use --squash if you don't want all those commits in the company repo)

To update just fetch and pull:

git fetch lib master
git subtree pull --prefix vendor/src/my-lib lib master

You can also commit local changes and push them back to your repo:

git subtree push --prefix vendor/src/my-lib lib master

Users of the company repo don't need to bother with all of this, they can work with the repo in the usual ways.

A (much more detailed) description of the above can also be found in this Atlassian blog entry.


They won't use a submodule or clone my repository during build time.

I think this is an XY problem. They and/or you do not seem to understand what a fork is or how to maintain it. It would not be cloned during build time. It would be cloned once when the project is set up, and remain completely under their control just like the rest of their project. They could keep the original version forever, or update it from your upstream version as they see fit.

  • They want a solution that can be built entirely with git, cmake, and a compiler such that the entire project can be built with git clone their-repo-url; cmake .; make;. So a fork alone doesn't solve that problem unless it is cloned and referenced by cmake. Regardless, a fork is not an acceptable solution. I'm not looking for what's wrong with their logic, but how to work with it regardless of how dumb it may seem.
    – Neal Kruis
    Commented Feb 9, 2017 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.