{"thread":{"id":"23745","subject":"anything behaviourally like perforce branch-spec mappings in git?","startedAt":"2010-05-08T13:39:20Z","lastAt":"2010-05-08T13:39:20Z","messageCount":1,"participants":["Robert Buck"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"141247","messageId":"AANLkTikAPyfkAXLstPdEWyq2mKM0uBP1khSUV5t4-I23@mail.gmail.com","threadId":"23745","inReplyTo":null,"subject":"anything behaviourally like perforce branch-spec mappings in git?","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-08T13:39:20Z","receivedAt":"2010-05-08T13:39:20Z","isPatch":false,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"Back at VeriSign we used branch-specs in Perforce to normalize\nchecked-in tooling to standard names (without version numbers). For\nexample:\n\nChecked into the Perforce \"releng\" depot was the following:\n\n//releng/\n  head/\n    vendor/\n      junit-4.1/\n        junit-4.1.jar\n      junit-4.3\n        junit-4.3.jar\n  branches/\n     same as above...\n\nAnd a product specific depot may be:\n\n//general\n  head/\n    ...\n  branches/\n    ...\n\nThe branch spec for a product would be:\n\n//releng/branches/branch-name/vendor/junit-4.1   //workspace/releng/vendor/junit\n...\n\nYou should be able to get the point. We supported workspace\ncomposition, and the neat thing was that the build system itself was\nversioned and could be separately versioned and changed as though it\nwere itself a product. But, as the build system was Ant based, rather\nthan constantly changing the build system to adapt to new versions of\njunit, oro, and ivy jars, we simply used branch and view specs to\nneutralize the workspace so the build system only referred to names\nthat lack version numbers. Further, a product could upgrade to a newer\nversion of the build system, almost always without consequence just by\nchanging these mappings.\n\nSo, is there some way to similarly accomplish this in Git? It was a\nhuge time-saver for release engineering at VeriSign, a pattern I'd\nlike to replicate using Git.\n\n- Bob\n"}]}