1

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?

  • 1
    Sounds like broadcom SDK... – liberforce Nov 16 '18 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 '18 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 '18 at 0:02
3

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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