We have n C projects which reference 4 different versions of a device SDK - 12.3, 13.1, 15.0, and 15.2. There is no public upstream repo for the SDK - it is released as a zip file. We need to patch the SDK to work for our particular needs, and would like to minimize copy-paste code sharing.

I would like to put the SDK versions in a git repo to share the current state of our patches between our n projects. My plan is to put all SDK versions as branches from a (mostly) empty master branch.

Is this a common best practice? If not, what is the common best practice for tracking local changes to unversioned 3rd party code, with dependencies on several releases?

  • 2
    Sounds like broadcom SDK...
    – liberforce
    Nov 16, 2018 at 11:00
  • Here is an interesting Blog post about this. It is a bit of a rant, but if your take the time and read the comments to it, you will probably find some good recommendations there.
    – Doc Brown
    Nov 16, 2018 at 17:23
  • @DocBrown I had read that (and the comments) the day before posting this, which was one of the factors influencing the solution I've proposed in my question :).
    – Iiridayn
    Nov 20, 2018 at 0:02

1 Answer 1


Yes, it would be reasonable to store them as branches that way. It would even be worth tagging the original releases so they're super easy to get to. I would also suggest creating the branches as orphans or at least not having a dummy empty master branch.

Your Answer

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

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