{"thread":{"id":"9262","subject":"Can you do this with GIT?","startedAt":"2007-07-27T18:02:37Z","lastAt":"2007-07-27T20:08:06Z","messageCount":7,"participants":["CPD","Johannes Schindelin","Linus Torvalds","Ray Lehtiniemi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48809","messageId":"11834063.post@talk.nabble.com","threadId":"9262","inReplyTo":null,"subject":"Can you do this with GIT?","fromName":"CPD","fromEmail":"cdavidson@altsoftware.com","sentAt":"2007-07-27T18:02:37Z","receivedAt":"2007-07-27T18:02:37Z","isPatch":false,"sender":{"key":"cdavidson@altsoftware.com","avatar":null},"body":"\nHi All,\n\nI hope this is the right forum, it's all I could find. Sincere apologies in\nadvance if I in the wrong place.\n\nI set up a source control system for the company around CVS, but GIT has\nsome very attractive features and I'd like to migrate if it can do some\nother things that we need.\n\nWe produce variations based on a (mostly) common codebase. In CVS I set up\n\"environment\" modules for each platform, then when you are working on that\nplatform, you simply check out the correct environment and build. Only the\nneeded code and tools are exposed in that environment (this is important as\nclients must NOT see each other's code and most customers have some\ncustomization). I do this by defining and renaming modules in the CVSROOT\nmodules file.\n\nDoes GIT support anything like this? Or another way to acheive the same end?\n\nThanks muchly, in advance, Colin\n-- \nView this message in context: http://www.nabble.com/Can-you-do-this-with-GIT--tf4159350.html#a11834063\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"48820","messageId":"Pine.LNX.4.64.0707272002250.14781@racer.site","threadId":"9262","inReplyTo":"11834063.post@talk.nabble.com","subject":"Re: Can you do this with GIT?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-27T19:05:46Z","receivedAt":"2007-07-27T19:05:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Jul 2007, CPD wrote:\n\n> I hope this is the right forum, it's all I could find. Sincere apologies \n> in advance if I in the wrong place.\n\nYou might be interested in http://git.or.cz: there is a lot of useful \ninformation to find; amongst others what is the right forum...\n\nSo yes, this is the right forum.\n\n> I set up a source control system for the company around CVS, but GIT has\n> some very attractive features and I'd like to migrate if it can do some\n> other things that we need.\n> \n> We produce variations based on a (mostly) common codebase. In CVS I set \n> up \"environment\" modules for each platform, then when you are working on \n> that platform, you simply check out the correct environment and build. \n> Only the needed code and tools are exposed in that environment (this is \n> important as clients must NOT see each other's code and most customers \n> have some customization). I do this by defining and renaming modules in \n> the CVSROOT modules file.\n\nI would use branches for that.  A base branch with the common code, and \nthe customisations in all the branches, which merge from the base branch.\n\nIf you have an interesting change in a custom branch, you can percolate \nthat back into the base branch, by checking out that base branch and \ncherry-picking the commit you want to have.\n\nOf course, you can automate this merging (or even rebasing, if you are \ninterested in keeping your customisations nice and tidy) with a script.  \nWith a git alias even.\n\nHth,\nDscho\n"},{"id":"48830","messageId":"200707271345.03300.rayl@mail.com","threadId":"9262","inReplyTo":"Pine.LNX.4.64.0707272002250.14781@racer.site","subject":"Re: Can you do this with GIT?","fromName":"Ray Lehtiniemi","fromEmail":"rayl@mail.com","sentAt":"2007-07-27T19:45:03Z","receivedAt":"2007-07-27T19:45:03Z","isPatch":false,"sender":{"key":"rayl@mail.com","avatar":null},"body":"On Friday 27 July 2007 13:05, Johannes Schindelin wrote:\n> On Fri, 27 Jul 2007, CPD wrote:\n\n> > We produce variations based on a (mostly) common codebase. In CVS I set\n> > up \"environment\" modules for each platform, then when you are working on\n> > that platform, you simply check out the correct environment and build.\n> > Only the needed code and tools are exposed in that environment (this is\n> > important as clients must NOT see each other's code and most customers\n> > have some customization). I do this by defining and renaming modules in\n> > the CVSROOT modules file.\n>\n> I would use branches for that.  A base branch with the common code, and\n> the customisations in all the branches, which merge from the base branch.\n\nthis would break down if there were client-specific modules in the base \nbranch, though... how could those be hidden from the other clients?\n\n\nray\n"},{"id":"48829","messageId":"alpine.LFD.0.999.0707271236410.3442@woody.linux-foundation.org","threadId":"9262","inReplyTo":"11834063.post@talk.nabble.com","subject":"Re: Can you do this with GIT?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-27T19:45:35Z","receivedAt":"2007-07-27T19:45:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 27 Jul 2007, CPD wrote:\n> \n> We produce variations based on a (mostly) common codebase. In CVS I set up\n> \"environment\" modules for each platform, then when you are working on that\n> platform, you simply check out the correct environment and build. Only the\n> needed code and tools are exposed in that environment (this is important as\n> clients must NOT see each other's code and most customers have some\n> customization). I do this by defining and renaming modules in the CVSROOT\n> modules file.\n> \n> Does GIT support anything like this? Or another way to acheive the same end?\n\nDepending on how big the individual pieces are, you can do it either with \nbranches or subprojects.\n\nIf the \"mostly common\" codebase means that 90% of it really ends up being \ncommon, and what you have is a few config things and perhaps a library or \ntwo that either shows up or not, git branches would work really well. \n\nAnd branches are totally independent of each other, so it's quite possible \nto have even \"secret\" things in one branch, and it would never get exposed \nto anybody else. The biggest worry you'd need to make sure of is that you \ndon't want to merge such private branches directly with each other - since \nthen the merged branch would see everything that was in the history of the \nother branch, even if the merge itself ended up not picking the \"secret \nstuff\".\n\nSo with branches that have private information, you'd have to have one \n\"common\" branch that doesn't have any of the private stuff at all, and do \nthe general development on that, and then you can merge that common stuff \ninto all the individual private branches (and if you want to go the other \nway, moving something from a private branch to the \"common area\", you'd \nhave to cherry-pick just that particular detail into the common branch).\n\nIf you have bigger building blocks, and some of the whole building blocks \nneed to be private, you'd probably want to use the subproject support, \nwhich would make for more of a CVS \"modules\" kind of thing and in that \nsense perhaps closer to what you do now, but I suspect that just using \nbranches would actually end up being much simpler for you. It would depend \nmostly on how big those building blocks that you need to keep separate \nare.\n\n\t\tLinus\n"},{"id":"48831","messageId":"Pine.LNX.4.64.0707272048280.14781@racer.site","threadId":"9262","inReplyTo":"200707271345.03300.rayl@mail.com","subject":"Re: Can you do this with GIT?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-27T19:49:59Z","receivedAt":"2007-07-27T19:49:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Jul 2007, Ray Lehtiniemi wrote:\n\n> On Friday 27 July 2007 13:05, Johannes Schindelin wrote:\n> > On Fri, 27 Jul 2007, CPD wrote:\n> \n> > > We produce variations based on a (mostly) common codebase. In CVS I set\n> > > up \"environment\" modules for each platform, then when you are working on\n> > > that platform, you simply check out the correct environment and build.\n> > > Only the needed code and tools are exposed in that environment (this is\n> > > important as clients must NOT see each other's code and most customers\n> > > have some customization). I do this by defining and renaming modules in\n> > > the CVSROOT modules file.\n> >\n> > I would use branches for that.  A base branch with the common code, and\n> > the customisations in all the branches, which merge from the base branch.\n> \n> this would break down if there were client-specific modules in the base \n> branch, though... how could those be hidden from the other clients?\n\nUmm.  Don't put the client-specific modules in the base branch, then?  The \nbase branch is the common code, the code that every client may look at.  \nNothing else.\n\nMaybe I did not get the whole picture...  do you want your _clients_ to \naccess your main repo with Git?\n\nCiao,\nDscho\n"},{"id":"48833","messageId":"200707271352.11147.rayl@mail.com","threadId":"9262","inReplyTo":"11834063.post@talk.nabble.com","subject":"Re: Can you do this with GIT?","fromName":"Ray Lehtiniemi","fromEmail":"rayl@mail.com","sentAt":"2007-07-27T19:52:11Z","receivedAt":"2007-07-27T19:52:11Z","isPatch":false,"sender":{"key":"rayl@mail.com","avatar":null},"body":"On Friday 27 July 2007 12:02, CPD wrote:\n\n> We produce variations based on a (mostly) common codebase. In CVS I set up \n> \"environment\" modules for each platform, then when you are working on that\n> platform, you simply check out the correct environment and build. Only the\n> needed code and tools are exposed in that environment (this is important as\n> clients must NOT see each other's code and most customers have some\n> customization). I do this by defining and renaming modules in the CVSROOT\n> modules file.\n\nthis sounds very close to what i'm trying to achieve at the moment.\n\n\n> Does GIT support anything like this? Or another way to acheive the same\n> end?\n\ni couldn;t find any ready way to do it.... but i've hacked up a few \npreliminary thoughts on how this might work in git.  comments and feedback \nare welcome :-)\n\nthe basic idea is to import each snapshot of each vendor release as a tagged \nroot commit, then push all these tagged root commits into a central \"library\" \nrepository. each tagged root commit stands alone and functions as a cvs \nmodule.\n\nlibrary repos are set up as remotes under git, and a simple script will import \na set of snapshots into a brand new project as a baseline for customization.\n\nthe three shell scripts, and the two control files used by them, are included \nhere:\n\n==> vendor-tracking.sh <==\n###########################################################\n#\n# Import a vendor snapshot into a \"library\" repository.\n#\n# To import a vendor snapshot, unzip the snapshot into\n# a new folder.  Then go into the folder and type\n#\n#  xxx-import <library> <tag>\n#\n# This will create an empty git repo in the current\n# snapshot folder and create a root commit in \n# it which holds the snapshot.  This root commit will be\n# tagged as \"tag\" and then pushed into the \"library\" repo.\n#\n# No error checking is done.\n#\n###########################################################\nxxx-import ()\n{(\n\trepo=$1\n\ttag=$2\n\n\texport GIT_DIR=/tmp/$$.$tag\n\n\trm -rf $GIT_DIR\n\tmkdir -p $GIT_DIR\n\n\tgit init\n\tgit add .\n\tgit commit -s -m \"Import $tag\"\n\tgit tag $tag master\n\tgit push $repo refs/tags/$tag:refs/tags/$tag\n\n\trm -rf $GIT_DIR\n)}\n\n###########################################################\n#\n# Use a vendor release in the current project.\n#\n# To use a copy of some vendor snapshot in the current\n# project, go to the top level of your current project,\n# then type\n#\n#  xxx-use <library> <tag> <path>\n#\n# The tagged snapshot will be fetched from the library\n# and deposited into the <path> subdirectory, then committed\n# to the project.\n# \n# No error checking is done.\n#\n###########################################################\nxxx-use ()\n{(\n\trepo=$1\n\ttag=$2\n\tpath=$3\n\n\tgit fetch $repo refs/tags/$tag:refs/tags/$tag\n\tgit read-tree --prefix=$path/ $tag\n\tgit commit -s -m \"Use $tag as $path\"\n)}\n\n###########################################################\n#\n# Create a new project from a set of vendor components.\n#\n# To start a new project with a known array of vendor\n# components, create a remotes file describing the libraries\n# and an manifest file describing the components and how they\n# will be used. Then, in a new folder, type\n#\n#  xxx-start <remotes> <manifest>\n#\n# This will create a new Git project in the current folder,\n# add a remote for each library repository, then proceed to\n# fetch and commit each vendor component into the new project.\n# The new project is now ready to be customized.\n# \n# No error checking is done.\n#\n###########################################################\nxxx-start ()\n{(\n\tremotes=$1\n\tmanifest=$2\n\n\tgit init\n\n\tcat $remotes |\n\twhile read name url\n\tdo\n\t\tgit remote add $name $url\n\tdone\n\n\tcat $manifest |\n\twhile read path remote tag\n\tdo\n\t\txxx-use $remote $tag $path\n\tdone\n\n\tgit checkout -f master\n)}\n\n\n==> remotes <==\nlib1\tssh://me@home.com/home/me/work/library\nlib2\t//filesrv/git/library\n\n==> manifest <==\npath/to/A\t\tlib1\tvendorA/componentA/version1\npath/to/B\t\tlib2\tvendorB/componentB/version2\n\n\n\n\n\n\ni would prefer to import and tag raw tree objects, since i get some of my \nsnapshots as pre-assembled collections of (modified copies of) several \ncomponents.  it would therefore be convenient to have several tags per \nsnapshot pointing at the subtrees corresponding to each component.  however,  \nfetch and push seem to prefer commits over trees.... \n\nas it stands, the vendor snapshots have no \"history\" to them.  each snapshot \nstands in isolation.  there was an interesting thread a few days ago about \nimporting ancient kernel history as a series of trees, then \"stitching \ntogether\" a \"synthetic history\" from a collection of trees.  i would see \nsomething like that as the basis for \"vendor tracking branches\", which could \nbe restitched if an older snapshot is received \"out of order\".\n\n\nhope it helps\nray\n"},{"id":"48834","messageId":"200707271408.07108.rayl@mail.com","threadId":"9262","inReplyTo":"Pine.LNX.4.64.0707272048280.14781@racer.site","subject":"Re: Can you do this with GIT?","fromName":"Ray Lehtiniemi","fromEmail":"rayl@mail.com","sentAt":"2007-07-27T20:08:06Z","receivedAt":"2007-07-27T20:08:06Z","isPatch":false,"sender":{"key":"rayl@mail.com","avatar":null},"body":"On Friday 27 July 2007 13:49, Johannes Schindelin wrote:\n> Hi,\n>\n> On Fri, 27 Jul 2007, Ray Lehtiniemi wrote:\n> > On Friday 27 July 2007 13:05, Johannes Schindelin wrote:\n> > > On Fri, 27 Jul 2007, CPD wrote:\n> > > > We produce variations based on a (mostly) common codebase. In CVS I\n> > > > set up \"environment\" modules for each platform, then when you are\n> > > > working on that platform, you simply check out the correct\n> > > > environment and build. Only the needed code and tools are exposed in\n> > > > that environment (this is important as clients must NOT see each\n> > > > other's code and most customers have some customization). I do this\n> > > > by defining and renaming modules in the CVSROOT modules file.\n> > >\n> > > I would use branches for that.  A base branch with the common code, and\n> > > the customisations in all the branches, which merge from the base\n> > > branch.\n> >\n> > this would break down if there were client-specific modules in the base\n> > branch, though... how could those be hidden from the other clients?\n>\n> Umm.  Don't put the client-specific modules in the base branch, then?  The\n> base branch is the common code, the code that every client may look at.\n> Nothing else.\n\nyes, i don;t think there's any other way to do it with branches (and just be \ncareful not to merge the private branches back! :-)\n\n\n> Maybe I did not get the whole picture...  do you want your _clients_ to\n> access your main repo with Git?\n\nnot in my case, anyway... although if you define \"client\" to \ninclude \"subcontractor\", then yes, i'd be interested in going down that \nroad... sometimes there are pieces which they aren't licensed to see, but if \nwe could somehow track their work in a separate repo and then easily merge it \nback into the fully licensed tree, that would have great value.\n\nfrom the original message, i also keyed on \"Only the needed code and tools are \nexposed in that environment\".  this is something i'd like to see too... i'm \nworking in a software eco-system with hundreds of standalone components, and \nwould like the ability to pick and choose a small handful of those for any \ngiven project, without pulling in reams of history on the stuff i'm not \nusing...\n\nthanks\nray\n\n\n>\n> Ciao,\n> Dscho\n"}]}