{"thread":{"id":"3666","subject":"Subprojects: a user perspective","startedAt":"2006-03-18T02:11:45Z","lastAt":"2006-03-18T02:11:45Z","messageCount":1,"participants":["R. Steve McKown"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17634","messageId":"200603171911.45725.rsmckown@yahoo.com","threadId":"3666","inReplyTo":null,"subject":"Subprojects: a user perspective","fromName":"R. Steve McKown","fromEmail":"rsmckown@yahoo.com","sentAt":"2006-03-18T02:11:45Z","receivedAt":"2006-03-18T02:11:45Z","isPatch":false,"sender":{"key":"rsmckown@yahoo.com","avatar":null},"body":"We are looking to migrate from CVS to a distributed VCS like git.  I've read \nthe discussions on this list WRT subprojects and wanted to present another \nuser's perspective.  The history of this list is active, so I apologize if my \npost is redundant or unwanted.  Send flames my way!  ;^)\n\nOur repository is relatively large and extensively uses the CVS vendor branch \nfeature to use and track software components managed by other groups, such as \nthe linux kernel, openssl, busybox, uclibc, etc.  These are the tasks that we \nperform to manage components:\n\n1. Occasionally import new revisions of components we use into\n   the component's private branch (like an incoming branch).\n   This provides a version history of each component's \"pristine\n   source\" as used within the project over its lifetime.\n\n2. Each component gets a subdirectory in the project branch(es).\n   Component versions are merged from the component's incoming\n   branch into this subdirectory as new components or component\n   revisions are incorporated into the project.\n\n3. Local modifications, as necessary, are made to component\n   code within the project branch(es), not the incoming\n   branches which only hold pristine sources.\n\n4. Patches of local changes made to a component, like for\n   submission to the upstream maintainer, are built by diffing\n   a project branch's component subdir with the component's\n   incoming branch.\n\nI think git can do all of this if the component incoming branches have the \nsame path information as the project branches.  In other words, if the \nproject places the busybox component at /src/components/busybox, then the \nbusybox incoming branch must place the busybox code \ninto /src/component/busybox.\n\nSo, in terms of adding specific support for subprojects, the only thing I see \nthat could be improved would be the ability to reference a sub-tree in git \noperations that currently expect a tree (aka tree-ish or refspec parameters).  \nI liked Junio's concept of subproject linking, but only because it provided a \nway to conceptually address a sub-tree.\n\nWith sub-tree addressing, a component branch could be naturally rooted, and \ndiffing its head against the a project branch head at the component's subdir:\n\n   git diff linux-incoming proj-branch@/src/components/linux\n\nor merging a new linux version into the project:\n\n   git checkout linux-incoming\n   #suck in a new linux release from upstream\n   git commit -a\n   git tag linux-2.4.16\n   git checkout master\n   git pull . linux-2.4.16:.@/src/components/linux\n\nAll the best,\nSteve\n"}]}