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?
-
2Sounds like broadcom SDK...liberforce– liberforce2018年11月16日 11:00:20 +00:00Commented 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– Doc Brown2018年11月16日 17:23:29 +00:00Commented 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– Iiridayn2018年11月20日 00:02:53 +00:00Commented 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.
Explore related questions
See similar questions with these tags.