{"thread":{"id":"22132","subject":"Linking multiple Git repositories for version tracking","startedAt":"2010-01-08T17:03:58Z","lastAt":"2010-01-10T08:12:47Z","messageCount":4,"participants":["James Beck","Avery Pennarun","Michael Witten","Christoph Jahn"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"131111","messageId":"op.u574cwxqn3qeew@klee","threadId":"22132","inReplyTo":"op.u573txvdn3qeew@klee","subject":"Linking multiple Git repositories for version tracking","fromName":"James Beck","fromEmail":"james@jmbeck.com","sentAt":"2010-01-08T17:03:58Z","receivedAt":"2010-01-08T17:03:58Z","isPatch":false,"sender":{"key":"james@jmbeck.com","avatar":null},"body":"Hi,\n\nI'm developing firmware that is composed of multiple projects. Each  \nsection of the firmware has it's own git repository (each section  \ncorrelates to a physical processor). But the firmware as a whole is  \ngetting to the point where I have to remember which version of Firmware A  \nis compatible with Firmware B. If I add a feature to B that requires some  \ntweaks in A, I need to know that both A v3.04 and B v2.7 need to be used  \ntogether.\n\nI'm starting to move into alpha with this code, so I really need to have a  \nsystem that keeps track of compatible firmware versions. The best I can  \ncome up with is a plain text file (or Excel spreadsheet) that lists the  \noverall firmware version, and the Git hash for each individual project.  \nThat way, if I want to load up a particular firmware version, I can  \ncheckout each hash for that version. Seems foolproof, but not terribly  \neasy, and somewhat annoying.\n\nI know submodules might be used, but it's not super obvious how to make  \ntheir paradigm work nicely here. (You check out a version you want, and  \nthen list all the submodule git hashes for that version? What happens if  \none hash needs updating? Do you branch it?) It seems more complicated than  \nI'd like.\n\nBut this can't be a problem that only I have. What have you done to keep  \ntrack of software bundle versions?\n\nThanks!\nJames\n"},{"id":"131115","messageId":"32541b131001081034k67664652h6f6e9a007175c260@mail.gmail.com","threadId":"22132","inReplyTo":"op.u574cwxqn3qeew@klee","subject":"Re: Linking multiple Git repositories for version tracking","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-01-08T18:34:11Z","receivedAt":"2010-01-08T18:34:11Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Jan 8, 2010 at 12:03 PM, James Beck <james@jmbeck.com> wrote:\n> I'm developing firmware that is composed of multiple projects. Each\n> section of the firmware has it's own git repository (each section\n> correlates to a physical processor). But the firmware as a whole is\n> getting to the point where I have to remember which version of Firmware A\n> is compatible with Firmware B. If I add a feature to B that requires some\n> tweaks in A, I need to know that both A v3.04 and B v2.7 need to be used\n> together.\n>\n> I'm starting to move into alpha with this code, so I really need to have a\n> system that keeps track of compatible firmware versions. The best I can\n> come up with is a plain text file (or Excel spreadsheet) that lists the\n> overall firmware version, and the Git hash for each individual project.\n> That way, if I want to load up a particular firmware version, I can\n> checkout each hash for that version. Seems foolproof, but not terribly\n> easy, and somewhat annoying.\n>\n> I know submodules might be used, but it's not super obvious how to make\n> their paradigm work nicely here. (You check out a version you want, and\n> then list all the submodule git hashes for that version? What happens if\n> one hash needs updating? Do you branch it?) It seems more complicated than\n> I'd like.\n\nThis seems like exactly what submodules were designed to do.\n\n1. create a \"superproject\" for each physical product\n\n2. use submodules to link to the right firmware versions for that product\n\n3. when you make a new release of that physical product, update the\nfirmware links.\n\n4. when someone wants to check out a particular version of the\nproduct, they retrieve the product's repo and ask git submodule to\ncheckout the submodules.\n\nWhich part is not working for you?\n\nHave fun,\n\nAvery\n"},{"id":"131166","messageId":"b4087cc51001082125h37fc43f0t5f2a9809f558388c@mail.gmail.com","threadId":"22132","inReplyTo":"op.u574cwxqn3qeew@klee","subject":"Re: Linking multiple Git repositories for version tracking","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-01-09T05:25:33Z","receivedAt":"2010-01-09T05:25:33Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Jan 8, 2010 at 11:03 AM, James Beck <james@jmbeck.com> wrote:\n> I'm starting to move into alpha with this code, so I really need to have a\n> system that keeps track of compatible firmware versions. The best I can\n> come up with is a plain text file (or Excel spreadsheet) that lists the\n> overall firmware version, and the Git hash for each individual project.\n> That way, if I want to load up a particular firmware version, I can\n> checkout each hash for that version. Seems foolproof, but not terribly\n> easy, and somewhat annoying.\n\nThe Xorg project is currently composed of 197 separate `modules', and\nI believe that (practically) each has its own Git repo.\n\nTheir solution seems to be the exact same as yours, though it involves\ntranslating between official release numbers and commits from what I\nrecall, all of which uses this hand-written list:\n\n    http://cgit.freedesktop.org/xorg/util/modular/tree/module-list.txt\n\nSo, perhaps you just need to write a small script to do the checkouts\nautomatically for you.\n\nAlso, you could use Git tags rather than raw Git hashes. If you have\n\"releases\", you could just make the same tag name in each Git repo, so\nthat checking out any particular \"release\" just amounts to having a\nscript loop through the repos and checkout the necesarry commit using\nthe associated tag. In fact, I suggested this to the Xorg guys not\nlong ago:\n\n    http://www.mail-archive.com/xorg-devel@lists.x.org/msg03037.html\n\nSee:\n\n    http://cgit.freedesktop.org/xorg/util/modular/tree/\n    http://www.x.org/wiki/Development/Documentation/ReleaseHOWTO\n"},{"id":"131214","messageId":"hic25v$17i$1@ger.gmane.org","threadId":"22132","inReplyTo":"op.u574cwxqn3qeew@klee","subject":"Re: Linking multiple Git repositories for version tracking","fromName":"Christoph Jahn","fromEmail":"christoph.jahn@gmx.de","sentAt":"2010-01-10T08:12:47Z","receivedAt":"2010-01-10T08:12:47Z","isPatch":false,"sender":{"key":"christoph.jahn@gmx.de","avatar":null},"body":"I have had the very same issue a while ago when still using SVN (shame on \nme ;-). SVN offers a special tag \"svn:externals\" which is something like \nsymlinks. Having used it for a while I came to the conclusion that such a \nthing, as well-intentioned as it may be, is something I want to avoid by \nall means.\n\nThere are two reasons for that:\n- Lock-in\n- It is conceptually wrong\n\nThe conceptual part -which I consider to be more important- is mostly \nabout the fact that we are talking about dependency management and not \nversion control any more. Do I really want to \"hide\" dependencies inside \nthe VCS? Also, there may be different dependencies for compilation and \ntesting. That's why I chose to use Maven for this task.\n\nMy $0.02\n\n-- \nBest regards,\nChristoph\n"}]}