On Fri, Jan 8, 2010 at 12:03 PM, James Beck <james@xxxxxxxxxx> wrote: > I'm developing firmware that is composed of multiple projects. Each > section of the firmware has it's own git repository (each section > correlates to a physical processor). But the firmware as a whole is > getting to the point where I have to remember which version of Firmware A > is compatible with Firmware B. If I add a feature to B that requires some > tweaks in A, I need to know that both A v3.04 and B v2.7 need to be used > together. > > I'm starting to move into alpha with this code, so I really need to have a > system that keeps track of compatible firmware versions. The best I can > come up with is a plain text file (or Excel spreadsheet) that lists the > overall firmware version, and the Git hash for each individual project. > That way, if I want to load up a particular firmware version, I can > checkout each hash for that version. Seems foolproof, but not terribly > easy, and somewhat annoying. > > I know submodules might be used, but it's not super obvious how to make > their paradigm work nicely here. (You check out a version you want, and > then list all the submodule git hashes for that version? What happens if > one hash needs updating? Do you branch it?) It seems more complicated than > I'd like. This seems like exactly what submodules were designed to do. 1. create a "superproject" for each physical product 2. use submodules to link to the right firmware versions for that product 3. when you make a new release of that physical product, update the firmware links. 4. when someone wants to check out a particular version of the product, they retrieve the product's repo and ask git submodule to checkout the submodules. Which part is not working for you? Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html