{"thread":{"id":"31945","subject":"Workflow for templates?","startedAt":"2012-10-25T21:15:22Z","lastAt":"2012-11-10T12:32:50Z","messageCount":12,"participants":["Josef Wolf","Enrico Weigelt","Pyeron, Jason J CTR (US)","Holger Hellmuth (IKS)","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"201921","messageId":"20121025211522.GA28437@raven.wolf.lan","threadId":"31945","inReplyTo":null,"subject":"Workflow for templates?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2012-10-25T21:15:22Z","receivedAt":"2012-10-25T21:15:22Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"Hello everybody,\n\nI am looking for a setup where teplates can be handled easily.\n\nFor a better explanation of what I'm trying to achieve, I use the apache\nhttpd project as an example.\n\nApache httpd provides an extensively commented httpd.conf template, which\nusers can use as a starting point for their own customization.\n\nTha's fine so far. But I'd like this to work in both directions:\n\nDownstream: When the upstream template has new changes, I can merge them into\nmy local branch. Conflicts will remind me that I have to review my\ncustomization.\n\nUpstream: Within the customized working copy, I implement a new module or\nchange an existing one (e.g. mod_ssl). While implementing the new feature, I\nadd/modify my _customized_ template. When I'm happy with the new feature, I'd\nlike to rewrite the localized customization into something generic and send it\nalong with the implementation of the new feature to the upstream generic\ntemplate. My localized customization should not get lost during the\nprocess, of course.\n\nOne more important aspect: since the customized template might contain\nconfidential information, those bits should have a hard time to propagate to\nthe upstream repository.\n\nI guess the downstream part can be done by a vendor branch. But I have a hard\ntime to find a proper workflow for the upstream part.\n\nAny ideas?\n"},{"id":"202013","messageId":"3190de06-2eaf-4a39-91aa-9cc34c20fc8e@zcs","threadId":"31945","inReplyTo":"20121025211522.GA28437@raven.wolf.lan","subject":"Re: Workflow for templates?","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-10-27T18:45:45Z","receivedAt":"2012-10-27T18:45:45Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"Hi,\n\n<snip>\n\nI'd suggest a 3 level branch hierachy (IOW: the lower level\nis rebased ontop of the next higher level):\n\n* #0: upstream branch\n* #1: generic local maintenance branch\n* #2: per-instance cutomization branches\n\nNormal additions go to the lowest level #2. When you've got\nsome generic commit, you propagate it to the next level\n(cherry-pick) and rebase layer #2 ontop of it.\nNow you can send your layer #1 to upstream for integration.\n\nWhen upstream updated his branch, you simply rebase #1\nontop of it, do your checks etc, then proceed to rebasing #3.\n\nYou could also introduce more intermediate layers (eg when you've\ngot different groups of similar instance that share certain changes)\n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"202297","messageId":"20121031104403.GC28437@raven.wolf.lan","threadId":"31945","inReplyTo":"3190de06-2eaf-4a39-91aa-9cc34c20fc8e@zcs","subject":"Re: Workflow for templates?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2012-10-31T10:44:04Z","receivedAt":"2012-10-31T10:44:04Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Sat, Oct 27, 2012 at 08:45:45PM +0200, Enrico Weigelt wrote:\n> I'd suggest a 3 level branch hierachy (IOW: the lower level\n> is rebased ontop of the next higher level):\n> \n> * #0: upstream branch\n> * #1: generic local maintenance branch\n> * #2: per-instance cutomization branches\n> \n> Normal additions go to the lowest level #2. When you've got\n> some generic commit, you propagate it to the next level\n> (cherry-pick) and rebase layer #2 ontop of it.\n> Now you can send your layer #1 to upstream for integration.\n> \n> When upstream updated his branch, you simply rebase #1\n> ontop of it, do your checks etc, then proceed to rebasing #3.\n> \n> You could also introduce more intermediate layers (eg when you've\n> got different groups of similar instance that share certain changes)\n\nThanks for the suggestion, Enrico!\n\nI am somewhat unsure whether it would work this way. After all, there seems to\nbe an unbreakable rule with git: never rebase published branches.\n\nThus, once I have published my work to other people who also need to work on\nthe same localizations as I do, I have no longer the option of rebasing to get\nrid of the localizations and put the generic template stuff for upstream.\n\nI guess, my concern is because I have not yet fully understood the problems of\nrebasing, and how to recover from them.\n\nMaybe I should try to explain the problem in terms of repository\nhierarchy. Let's assume, there is this hierarchy of repositories:\n\nupstream: central repository, containing the generic template\n\nfoo-site: repository for site foo. Here we have localizations for a specific\n          administrative entity named foo (say, google).\n          This is where clones for production are made from, and production\n          boxes pull from here to be kept up-to-date.\n\nfoo-prodA: A clone of foo-site, put in production and pulling from a specific\n           branch on foo-site to receive released, blessed updates.\nfoo-prodB: Similar to foo-prodA, but on another box.\n           \nfoo-devA: A clone of foo-site to make development, releases, and whatever for\n          foo.\nfoo-devB: One more clone of foo-site, Developer B is working here.\n\nThen, we might have more administrative entities: bar-site, bar-prodA,\nbar-prodB, bar-devA, bar-devB, for example. This might be Microsoft, for\nexample.\n\nFurther, foo-devA might be the same person as bar-devA.\n\nSo when foo-devA pulls from foo-devB, then foo-devB will create problems when\nhe rebases after that pull.\n\nI think I have some kind of misunderstanding here, but I just can't figure\nwhat it is.\n\n\nMaybe I should try to explain the problem in yet other words:\n\nWhat I am trying to achieve, is to extend the workflow from development to\ndeployment across multiple administrative entities. As a picture:\n\n  upstream     (templates only).\n     ^\n     |\n     v\n  development  (configured, might contain experimental changes)\n     ^\n     |\n     v\n  deployment   (configured)\n\nThis workflow should not stop at administrative borders. Just replace foo by\ngoogle and bar by Microsoft to get an idea of what I am trying to achieve.\n"},{"id":"202596","messageId":"20121106195045.GD28437@raven.wolf.lan","threadId":"31945","inReplyTo":"20121031104403.GC28437@raven.wolf.lan","subject":"Re: Workflow for templates?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2012-11-06T19:50:45Z","receivedAt":"2012-11-06T19:50:45Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"No suggestions on this one?\n\nOn Wed, Oct 31, 2012 at 11:44:04AM +0100, Josef Wolf wrote:\n> I am somewhat unsure whether it would work this way. After all, there seems to\n> be an unbreakable rule with git: never rebase published branches.\n> \n> Thus, once I have published my work to other people who also need to work on\n> the same localizations as I do, I have no longer the option of rebasing to get\n> rid of the localizations and put the generic template stuff for upstream.\n> \n> I guess, my concern is because I have not yet fully understood the problems of\n> rebasing, and how to recover from them.\n> \n> Maybe I should try to explain the problem in terms of repository\n> hierarchy. Let's assume, there is this hierarchy of repositories:\n> \n> upstream: central repository, containing the generic template\n> \n> foo-site: repository for site foo. Here we have localizations for a specific\n>           administrative entity named foo (say, google).\n>           This is where clones for production are made from, and production\n>           boxes pull from here to be kept up-to-date.\n> \n> foo-prodA: A clone of foo-site, put in production and pulling from a specific\n>            branch on foo-site to receive released, blessed updates.\n> foo-prodB: Similar to foo-prodA, but on another box.\n>            \n> foo-devA: A clone of foo-site to make development, releases, and whatever for\n>           foo.\n> foo-devB: One more clone of foo-site, Developer B is working here.\n> \n> Then, we might have more administrative entities: bar-site, bar-prodA,\n> bar-prodB, bar-devA, bar-devB, for example. This might be Microsoft, for\n> example.\n> \n> Further, foo-devA might be the same person as bar-devA.\n> \n> So when foo-devA pulls from foo-devB, then foo-devB will create problems when\n> he rebases after that pull.\n> \n> I think I have some kind of misunderstanding here, but I just can't figure\n> what it is.\n> \n> \n> Maybe I should try to explain the problem in yet other words:\n> \n> What I am trying to achieve, is to extend the workflow from development to\n> deployment across multiple administrative entities. As a picture:\n> \n>   upstream     (templates only).\n>      ^\n>      |\n>      v\n>   development  (configured, might contain experimental changes)\n>      ^\n>      |\n>      v\n>   deployment   (configured)\n> \n> This workflow should not stop at administrative borders. Just replace foo by\n> google and bar by Microsoft to get an idea of what I am trying to achieve.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"202598","messageId":"871B6C10EBEFE342A772D1159D13208537AA184A@umechphj.easf.csd.disa.mil","threadId":"31945","inReplyTo":"20121106195045.GD28437@raven.wolf.lan","subject":"RE: Workflow for templates?","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-11-06T20:21:25Z","receivedAt":"2012-11-06T20:21:25Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"Maybe I lost sight of your problem. Can you give a specific example of where \"it\" does not work?\n\n> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n> Behalf Of Josef Wolf\n> Sent: Tuesday, November 06, 2012 2:51 PM\n> To: git@vger.kernel.org\n> Subject: Re: Workflow for templates?\n> \n> No suggestions on this one?\n> \n> On Wed, Oct 31, 2012 at 11:44:04AM +0100, Josef Wolf wrote:\n> > I am somewhat unsure whether it would work this way. After all, there\n> seems to\n> > be an unbreakable rule with git: never rebase published branches.\n> >\n> > Thus, once I have published my work to other people who also need to\n> work on\n> > the same localizations as I do, I have no longer the option of\n> rebasing to get\n> > rid of the localizations and put the generic template stuff for\n> upstream.\n> >\n> > I guess, my concern is because I have not yet fully understood the\n> problems of\n> > rebasing, and how to recover from them.\n> >\n> > Maybe I should try to explain the problem in terms of repository\n> > hierarchy. Let's assume, there is this hierarchy of repositories:\n> >\n> > upstream: central repository, containing the generic template\n> >\n> > foo-site: repository for site foo. Here we have localizations for a\n> specific\n> >           administrative entity named foo (say, google).\n> >           This is where clones for production are made from, and\n> production\n> >           boxes pull from here to be kept up-to-date.\n> >\n> > foo-prodA: A clone of foo-site, put in production and pulling from a\n> specific\n> >            branch on foo-site to receive released, blessed updates.\n> > foo-prodB: Similar to foo-prodA, but on another box.\n> >\n> > foo-devA: A clone of foo-site to make development, releases, and\n> whatever for\n> >           foo.\n> > foo-devB: One more clone of foo-site, Developer B is working here.\n> >\n> > Then, we might have more administrative entities: bar-site, bar-\n> prodA,\n> > bar-prodB, bar-devA, bar-devB, for example. This might be Microsoft,\n> for\n> > example.\n> >\n> > Further, foo-devA might be the same person as bar-devA.\n> >\n> > So when foo-devA pulls from foo-devB, then foo-devB will create\n> problems when\n> > he rebases after that pull.\n> >\n> > I think I have some kind of misunderstanding here, but I just can't\n> figure\n> > what it is.\n> >\n> >\n> > Maybe I should try to explain the problem in yet other words:\n> >\n> > What I am trying to achieve, is to extend the workflow from\n> development to\n> > deployment across multiple administrative entities. As a picture:\n> >\n> >   upstream     (templates only).\n> >      ^\n> >      |\n> >      v\n> >   development  (configured, might contain experimental changes)\n> >      ^\n> >      |\n> >      v\n> >   deployment   (configured)\n> >\n> > This workflow should not stop at administrative borders. Just replace\n> foo by\n> > google and bar by Microsoft to get an idea of what I am trying to\n> achieve.\n> > --\n> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n> > the body of a message to majordomo@vger.kernel.org\n> > More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"202601","messageId":"20121106210719.GG28437@raven.wolf.lan","threadId":"31945","inReplyTo":"871B6C10EBEFE342A772D1159D13208537AA184A@umechphj.easf.csd.disa.mil","subject":"Re: Workflow for templates?","fromName":"Josef Wolf","fromEmail":"jw@raven.inka.de","sentAt":"2012-11-06T21:07:19Z","receivedAt":"2012-11-06T21:07:19Z","isPatch":false,"sender":{"key":"jw@raven.inka.de","avatar":null},"body":"On Tue, Nov 06, 2012 at 08:21:25PM +0000, Pyeron, Jason J CTR (US) wrote:\n> Maybe I lost sight of your problem. Can you give a specific example of where \"it\" does not work?\n\nI guess it's _me_ who's lost. I can't figure how this is supposed to\nwork. Maybe you have an example?\n"},{"id":"202616","messageId":"509A863B.4090805@ira.uka.de","threadId":"31945","inReplyTo":"20121106210719.GG28437@raven.wolf.lan","subject":"Re: Workflow for templates?","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-11-07T16:03:07Z","receivedAt":"2012-11-07T16:03:07Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 06.11.2012 22:07, schrieb Josef Wolf:\n> On Tue, Nov 06, 2012 at 08:21:25PM +0000, Pyeron, Jason J CTR (US) wrote:\n>> Maybe I lost sight of your problem. Can you give a specific example of where \"it\" does not work?\n>\n> I guess it's _me_ who's lost. I can't figure how this is supposed to\n> work. Maybe you have an example?\n\nLet me ask a different question: What is wrong with cherry-picking \ndownstream changes to your upstream branch? Without rebasing it to \ndownstream.\n\nThat might mean there is a rather useless merge downstream later on, but \nthat's the price you pay for not doing the change in a development branch.\n"},{"id":"202735","messageId":"bbc40624-f95d-48c9-83ed-fd70430226a4@zcs","threadId":"31945","inReplyTo":"20121031104403.GC28437@raven.wolf.lan","subject":"Re: Workflow for templates?","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-11-10T07:13:49Z","receivedAt":"2012-11-10T07:13:49Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"\n> I am somewhat unsure whether it would work this way. After all, there\n> seems to\n> be an unbreakable rule with git: never rebase published branches.\n\nI dont see a big problem if you just tell the downstreams to rebase\ninstead of merge downwards.\n\nThat's eg. my default approach for handling things like local\ncustomizations. The fine thing here is that you'll always have a\nclear separation between upstream development and your customizations.\n\nLet's say, you have once forked at release tag v1.2.3, added 3\ncustomization commits and later rebase onto v1.2.4, you'll still\nhave your 3 customization commits ontop of the upstream release.\nWith merge, you'll get more and more merge commits mixed later\ncoming customizations, and a migh higher chance of repeating conflicts.\n\nI'd suggest some general rules:\n\n* strict branch hierachy\n* downstreams always rebase instead of merge\n* probably use --onto rebase\n* development is always happening in topic-branches, that will be\n  rebased before merge into their upstream --> fast-forward only\n\n> Maybe I should try to explain the problem in terms of repository\n> hierarchy. Let's assume, there is this hierarchy of repositories:\n\nLet's talk about branches instead - repos are just containers for\nbranches (and tags, etc). If all people are practically in the same\nadministrative domain (or sort of), you can even use one single\nrepo for that (not counting developer's and target system's local\nclones).\n\n> upstream: central repository, containing the generic template\n> \n> foo-site: repository for site foo. Here we have localizations for a\n> specific\n>           administrative entity named foo (say, google).\n>           This is where clones for production are made from, and\n>           production\n>           boxes pull from here to be kept up-to-date.\n\nOnly the non-customized boxes will pull from here - if there's any bit\nthat needs to be changed, add separate branches for them.\n\nAnd \"pull\" always means rebase.\n\nWhen a new upstream release comes out (and is properly validated), it\nwill be rebased ontop of that.\n\n> foo-devA: A clone of foo-site to make development, releases, and\n> whatever for foo.\n> foo-devB: One more clone of foo-site, Developer B is working here.\n\nDevelopers should use topic branches, which are regularily rebased\nontop of their upstream, especially before commit and final validation.\n\n> Further, foo-devA might be the same person as bar-devA.\n\nHe'll use separate branches anyways. Everything else is just a matter\nof proper naming scheme.\n\nFor example, if you're using a central (bare) repository (again: not\ncounting the developer's locl clones), you could use something like\nan <site>+\"/\" branch name prefix.\n\nBy the way: you really should use non-conflicting tag names (eg.\nadding some <site>+\"/\" or <site>+\"-\" prefix), otherwise you'll\neasiy run into conflicts, because per default retrieved and local\ntags will all be in some namespace - you'll probably dont like to\nset up separate namespaces for individual remotes (which is quite\neasy to forget ;-o). Better consider tag names to be really global.\n\n> So when foo-devA pulls from foo-devB, then foo-devB will create\n> problems when he rebases after that pull.\n\npull (or probably: remote update) is different from merge or rebase\nessentially, pull is a combination of remote update and an automatic\nmerge from or rebase onto (depending on the configuration) the\ncoresponding upstream branch.\n\n> What I am trying to achieve, is to extend the workflow from\n> development to\n> deployment across multiple administrative entities. As a picture:\n> \n>   upstream     (templates only).\n>      ^\n>      |\n>      v\n>   development  (configured, might contain experimental changes)\n>      ^\n>      |\n>      v\n>   deployment   (configured)\n> \n> This workflow should not stop at administrative borders. Just replace\n> foo by\n> google and bar by Microsoft to get an idea of what I am trying to\n> achieve.\n\nWe're talking about two entirely different things here:\n\na) repositories: container that hold references to histories\n   (branches, tags, etc)\n\nb) branches and their semantic releations\n\n\nRepositories:\n\nAs git is fully distributed, it doesnt really matter where repositories\nare. Developers (and other parties accessing the code) will most likely\nhave their own local clone. But \"clone of X\" means nothing more than just\nhappens to have some remote attachment to repo X.\n\nSo, the semantics of\n\n    git clone /path/to/my/funny-project\n\nis the same like:\n\n    ( git init funny-project && \\\n        cd cd funny-project && \\\n        git remote add origin /path/to/my/funny-project && \\\n        git remote update origin && \\\n        git checkout origin/master -b master )\n\nSo, let's look at the individual steps:\n\n   #1: git init funny-project\n   --> ( mkdir funny-project && cd funny-dir && git init )\n   --> creates an empty repository\n\n   #2: git remote add origin /path/to/my/funny-project\n   --> configures an remote called \"origin\" with url \"/path/to/my/funnly-project\"\n       and confgures it to sync the remote-side's references from refs/heads/*\n       to locally refs/remotes/origin/*, and remote-side's refs/tags/* to\n       locally refs/tags (without overwriting existing tag references)\n\n   #3: git remote update origin\n   --> do the actual syncing from remote \"origin\", get the remote ref list,\n       download all yet objects (that are required for the refs to be synced)\n       and adds/updates the refs into the according target namespaces\n       (BTW: if a branch was removed on remote side, the local copy in\n       refs/remotes/<remote-name>/* wont be deleted - you'll need to call\n       git remote prune <remote-name> for that)\n\n   #4: git checkout origin/master -b master\n   --> copies the current refs/remotes/origin/master ref to refs/heads/master\n       and checks out that new local branch (IOW: sets the refs/HEAD symbolic\n       ref to refs/heads/master and copies index and working tree from the\n       head commit)\n\nBranches are something completely different:\n\nLogically, a branch is a history of commits with parent-child-relationship\n(mathematically spoken, it's an directed acyclic graph): each commit may\nhave a variable number of parent commits.\n\nTechnically, what we usally call \"branch\" is in fact an name (reference\nin refs/heads/* namespace) which point at the head commit of that local\nbranch. When you do git commit, it creates a new commit object from the\nindex, adds some metadata (eg. your commit message) and sets the current \nbranch reference (usually that one where the symbolic reference refs/HEAD\npoints to) to the new commit object's SHA-key. IOW: you add a new object\nin front of the DAG and move the pointer one step forward in the line.\n\nWhen you do a merge (no matter if the source is remote or local - it just\nneeds to be an locally available object), there're essentially two things\nthat can happen:\n\na) your source is an direct descendant of the target branch (IOW: the\n   target's current head commit appears somewhere in the source's history),\n   it will just move the current branch forward to the merge source\n   (moves the head pointer and updates index and worktree)\n   this is called \"fast-forward\" (in fact, it the fastest kind of merge)\n\nb) your source is not direct descendant: source tree will be actually\n   merged into index/worktree, possibly make break when there're conflicts\n   to be resolved manually, and create a new commit containing the current\n   (now merged) index and two parent poiters, to source and to previous\n   merge target.\n\nNow what is rebase ?\n\nA rebase rewrites history in various ways (in fact, you can do a lot more\nthings than just simple rebasing, eg. edit or drop older commits, etc).\n\nFor example 'git rebase origin/master' will look for the latest common\nancestor of both the current and the target treeish (eg. refs/remotes/master),\nstart from that tree'ish and apply the changes that happend from the last\ncommon ancestor until your current branch head ontop of that treeish,\n(possibly asking the user to manually resolve some conflicts), and then\nreplaces the current branch head by the final head.\n\nAs it changes history, it should be used wisely.\n\nA common problem with using rebase and public branches is:\n\n* upstream changes history (eg. because he rebased onto his upstream)\n* downstream (per default) merges this upstream into his branch\n--> git will see two entirely different branches get merged, so\n    there's some good change of nasty conflicts, and history will\n    easily get really ugly\n\nSo, if you do rebase your public branch, downstreams should also do so\n(rebase their local branches ontop of your public branch instead of\nmerging yours into theirs).\n\nBy the way: there are several more kinds of rebases, which are very\ninteresting for complex or sophisticated workflows, eg:\n\n* --ontop rebase: instead of letting git find out the starting point\n  of commit sequence to apply on target treeish, you'll define it\n  explicitly (eg. if you want it to forget about things previous to\n  the starting treeish).\n* interactive rebase: \n  a) is able to reconstruct merges\n  b) allows to cut into the sequence and change, drop or add new commits\n\nThese operations are very useful for cleaning up the history, especially\nwith things like topic-branch workflow (eg. if you originally have some\nhackish and unclean commits and you wanna put an clean and self-consistant\none into your mainline instead).\n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"202736","messageId":"f3537815-e1ea-4242-ac49-9d5a1e4f0511@zcs","threadId":"31945","inReplyTo":"509A863B.4090805@ira.uka.de","subject":"Re: Workflow for templates?","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-11-10T07:27:10Z","receivedAt":"2012-11-10T07:27:10Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"\n> Let me ask a different question: What is wrong with cherry-picking\n> downstream changes to your upstream branch? Without rebasing it to\n> downstream.\n\nNaah, dont rebase the upstream ontop of downstream - this doenst make\nany sense (yeah, my devs sometimes doing exatly this wong ;-o).\n\nInstead, as you just said, cherry-pick the good commits into your\nupstream branch and rebase your downstreams ontop of that. (doesnt\nmake any difference if this is done by different people or in different\nadministrative domains).\n\n> That might mean there is a rather useless merge downstream later on,\n> but that's the price you pay for not doing the change in a development\n> branch.\n\nThat's one of the things rebase is for: not having your history filled\nup with merges at all, but always have your local cutomizations added\nontop of the current upstream.\n\nBy the way: I'm also using this hierachy for package maintenance to\ndifferent target distros:\n\n   upstream branch\n         |\n         |----> upstream release tag X.Y.Z\n         |\n        \\ /\n   bugfix branch (maint-X-Y-Z) => general (eg. distro-agnostig) fixes go here\n         |\n         |-----> maintenance release tag X.Y.Z.A\n         |\n        \\ /\n   dist branch (mydist-X-Y-Z) => distro-specific customizations (eg.\n         |                       packaging control files, etc) go here\n         |------> dist package release tags X.Y.Z.A-B\n\n\nUsually I do quick hotfixes in the dist branch (and assigning new dist version number),\nthen copy the dist branch into some topic-branch, rebase into latest bugfix branch,\ncherry-pick the interesting commit(s) into the bugfix branch. When I do a new bugfix\nrelease (from by bugfix branch), I rebase the dist branch ontop the latest bugfix\nrelease tag, fix dist-package version numbers and run the dist-specific build and \ntesting pipeline.\n\nHere's some example for it: https://github.com/vnc-biz/redmine-core\n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"202744","messageId":"F9FF8107FA8F4CBD8C3D87B907BAE9E3@PhilipOakley","threadId":"31945","inReplyTo":"bbc40624-f95d-48c9-83ed-fd70430226a4@zcs","subject":"Re: Workflow for templates?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2012-11-10T09:55:13Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Enrico Weigelt\" <enrico.weigelt@vnc.biz> Sent: Saturday, November\n10, 2012 7:13 AM\n\nI've picked out Enrico's key points.\n\n>> Maybe I should try to explain the problem in terms of repository\n>> hierarchy. Let's assume, there is this hierarchy of repositories:\n>\n> Let's talk about branches instead - repos are just containers for\n> branches (and tags, etc).\n\nThis is often the key point that requires the 'new mindset'. Most folk\nuse/used the directory heirarchy (subtle distinction with the .git\n'repo' directory heirarchy to be noted) as a way of separating ownership\nbetween groups. They find it very hard to undo the old mindset and use\nbranches _instead of_ directories for the different group\nconfigurations.\n\nTeaching git is easy. Undoing the old mindset is hard hard hard. [it's\nstill hard]\n\n\n> By the way: you really should use non-conflicting tag names (eg.\n> adding some <site>+\"/\" or <site>+\"-\" prefix), otherwise you'll\n> easiy run into conflicts, because per default retrieved and local\n> tags will all be in some namespace\n>          Better consider tag names to be really global.\n\nDefinitely.\n\nApologies if it's a bit of bike-shedding.\n\nPhilip\n"},{"id":"202745","messageId":"7f1bbe94-b3f6-4728-960d-19e89e8e4166@zcs","threadId":"31945","inReplyTo":"F9FF8107FA8F4CBD8C3D87B907BAE9E3@PhilipOakley","subject":"Re: Workflow for templates?","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-11-10T10:29:33Z","receivedAt":"2012-11-10T10:29:33Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"\n> This is often the key point that requires the 'new mindset'. Most\n> folk\n> use/used the directory heirarchy (subtle distinction with the .git\n> 'repo' directory heirarchy to be noted) as a way of separating\n> ownership\n> between groups. They find it very hard to undo the old mindset and\n> use\n> branches _instead of_ directories for the different group\n> configurations.\n\nhmm, is this really a psychological issue ?\n\nwell, many years ago, i've seen a talk about git (maybe by linus himself),\nwhich started with something like \"forget everything you know abozt scm\" ...\n\n> > By the way: you really should use non-conflicting tag names (eg.\n> > adding some <site>+\"/\" or <site>+\"-\" prefix), otherwise you'll\n> > easiy run into conflicts, because per default retrieved and local\n> > tags will all be in some namespace\n> >          Better consider tag names to be really global.\n> \n> Definitely.\n\nWell, you *could* setup special fetch rules, which put tags from separate\nrepos to separate namespaces, but i'd really advice against that, as it's\ntoo easy to forget something and again mess it up.\n\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"202751","messageId":"E2479326E6B94EFEAEE8816FD926F36F@PhilipOakley","threadId":"31945","inReplyTo":"7f1bbe94-b3f6-4728-960d-19e89e8e4166@zcs","subject":"Re: Workflow for templates?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2012-11-10T12:32:50Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Enrico Weigelt\" <enrico.weigelt@vnc.biz> Sent: Saturday, November \n10, 2012 10:29 AM\n>> This is often the key point that requires the 'new mindset'. Most\n>> folk\n>> use/used the directory heirarchy (subtle distinction with the .git\n>> 'repo' directory heirarchy to be noted) as a way of separating\n>> ownership\n>> between groups. They find it very hard to undo the old mindset and\n>> use\n>> branches _instead of_ directories for the different group\n>> configurations.\n>\n> hmm, is this really a psychological issue ?\n\nOh absolutely.   It is very very hard to unlearn stuff, especially bad \nhabits that have had to become ingrained to make them work adequately! \nIt's like re-learning an alternative to a well loved mnemonic. \"CLAP\".\n\n>\n> well, many years ago, i've seen a talk about git (maybe by linus \n> himself),\n> which started with something like \"forget everything you know abozt \n> scm\" ...\n\nMost folk don't know why the old way used to be right, and is now so \nwrong, so they can't rationalize the change. Hence find the change very \ndifficult.\n\n[Other than git..] Current SCM methods were established before the \nTitanic sank and are based on drawing office practice, and were \ntransfered and applied to code printouts (which are simply machining \ninstructions to a compiler). The modern zero cost replication of \n\"Master\" drawings/code printouts has destroyed the original reasons for \nthe old practices (protect the aluable unique master). Similarly the new \nparadigm of \"how can I verify that this is a proper copy of the master\" \nisn't understood.\n\nDefinately a psychological issue when your whole world is being turned \nupside down ;-)\n"}]}