{"thread":{"id":"24973","subject":"Workflow question: Topic -> Next w/ frequent API changes","startedAt":"2010-09-04T16:35:01Z","lastAt":"2010-09-04T23:54:28Z","messageCount":3,"participants":["Bryan Drewery","Jon Seymour"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"149854","messageId":"4C827535.9040907@shatow.net","threadId":"24973","inReplyTo":null,"subject":"Workflow question: Topic -> Next w/ frequent API changes","fromName":"Bryan Drewery","fromEmail":"bryan@shatow.net","sentAt":"2010-09-04T16:35:01Z","receivedAt":"2010-09-04T16:35:01Z","isPatch":false,"sender":{"key":"bryan@shatow.net","avatar":"https://gravatar.com/avatar/97f2135497453f52d450b5cc8a09910e12efea7dc520a25107afcc666ab9a182?d=mp&s=160"},"body":" Hi,\n\nI maintain a project at work using a similar workflow as git.git with 6\ndevelopers; I've\nread gitworkflows(7) and several of Junio's emails regarding his\nworkflow. The project\nis still maturing so we have frequent API/DB changes and do not maintain\nbackwards\ncompatibility very well.\n\nDevelopers base their topics off of Next, due to the frequent API/DB\nchanges not in Master, and\nare able to merge their topic branches into Next themselves once\ncompleted. They rebase\ntheir topic on top of Next at this point. They can't necessarily rebase\non Master here because\nthey may hit conflicts due to code not existing in Master yet.\n\nThis is my first problem, once the branch is ready to merge into Master,\nI have to rebase\nit on top of Master, then merge in, merge Master down into Next;\npolluting the history in\nNext with duplicated commits.\n\nThe other problem is that once their topic has been merged into Next,\nand before it has\nbeen merged into Master, it may be found that another commit is needed\non their topic\nto fix an issue. Due to frequent API/DB changes, they might 'git pull\nNext' into their topic\nbranch, so they can properly test the new fix. Obviously this makes\nthings difficult once\nthe topic is ready for Master, and I have to manually cherry-pick their\ncommits into a\nnew branch to get rid of the 100s of Next commits they merged in.\n\nWhat's the best solution for handling this? Should we just be resetting\nNext after releases\nto remove the pollution?\n\nI'm thinking that we need to incorporate subsystem maintaining/branching\nas well, and\ngroup up like subsystem changes into the same releases. Though we still\nrun into problems\nwhere every file in the system needs updating for new API. Perhaps our\nworkflow is just completely\nwrong?\n\nAny input would be appreciated.\n\nThanks in advance,\nBryan Drewery\n"},{"id":"149899","messageId":"AANLkTikT6R4-HMLNebwwsF0pxP_uBTdi=+QkAL2m1EL=@mail.gmail.com","threadId":"24973","inReplyTo":"4C827535.9040907@shatow.net","subject":"Re: Workflow question: Topic -> Next w/ frequent API changes","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-09-04T23:38:53Z","receivedAt":"2010-09-04T23:38:53Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Sun, Sep 5, 2010 at 2:35 AM, Bryan Drewery <bryan@shatow.net> wrote:\n>  Hi,\n>\n> I maintain a project at work using a similar workflow as git.git with 6\n> developers; I've\n> read gitworkflows(7) and several of Junio's emails regarding his\n> workflow. The project\n> is still maturing so we have frequent API/DB changes and do not maintain\n> backwards\n> compatibility very well.\n>\n> Developers base their topics off of Next, due to the frequent API/DB\n> changes not in Master, and\n> are able to merge their topic branches into Next themselves once\n> completed. They rebase\n> their topic on top of Next at this point. They can't necessarily rebase\n> on Master here because\n> they may hit conflicts due to code not existing in Master yet.\n>\n\nBasing on next is fine, provided you never rebuild next. But if you\nnever rebuild next, then\nit isn't really acting like a next branch - it really is master.If you\ndo rebuild next occasionally,\nthen you are asking for trouble because changes you thought were\nreverted out of\nnext will flow back via branches that were forked from the earlier\nversion of next (unless you are rigourous about\nwhich changes you accept into next)\n\nIf you can do team-wide daily or twice daily builds, tag those, and\nask your developers\nto base all their work on those tags. Tags are inherently stable and\nwell specified. A branch\nis inherently unstable and ill-specified [ When you say you based on\nnext, what commit do you mean exactly? Next on which machine? Next at\nwhat time? What is the pull history of that machine and the machine it\npulled from? ].\n\n> This is my first problem, once the branch is ready to merge into Master,\n> I have to rebase\n> it on top of Master, then merge in, merge Master down into Next;\n> polluting the history in\n> Next with duplicated commits.\n>\n\nThe first problem is the rebase onto master. If you are doing this,\nyou are guaranteeing a world of pain. You should be merging into\nmaster. If a topic's base is a previous tag from master plus a\nselected number of other fixes, then merging such topics into master\nshould be a no-brainer. Of course, if people are basing their work on\nsomething unstable like next, then their work will contain all measure\nof untested nastiness and a merge into master won't be practical. This\nis another reason to encourage developers to base their work on a\nwell-known, stable tag, and not the bleeding tip of some integration\nbranch like next.\n\nRule of thumb: never rebase anything that has been shared with anyone\nelse. If you are merging a change into next and then\nrebasing it onto master, you are breaking this rule. Rebasing is great\nand I do it often, but I keep such things to myself.\n\n> The other problem is that once their topic has been merged into Next,\n> and before it has\n> been merged into Master, it may be found that another commit is needed\n> on their topic\n> to fix an issue. Due to frequent API/DB changes, they might 'git pull\n> Next' into their topic\n> branch, so they can properly test the new fix. Obviously this makes\n> things difficult once\n> the topic is ready for Master, and I have to manually cherry-pick their\n> commits into a\n> new branch to get rid of the 100s of Next commits they merged in.\n>\n> What's the best solution for handling this? Should we just be resetting\n> Next after releases\n> to remove the pollution?\n\nIf the topic is based on a well known tag, the topic does not contain\nmerges from anything other than\nthe well known tag and a handful of other topics, then the answer is\nto simply update the topic with the fix\nand then remerge the topic into master (and into next and into any\nother dependent work).\n\n>\n> I'm thinking that we need to incorporate subsystem maintaining/branching\n> as well, and\n> group up like subsystem changes into the same releases. Though we still\n> run into problems\n> where every file in the system needs updating for new API. Perhaps our\n> workflow is just completely\n> wrong?\n>\n> Any input would be appreciated.\n>\n\nI also wrote a post a little while back about maintaining a private\nworking branch:\n\n   http://permalink.gmane.org/gmane.comp.version-control.git/153168\n\nThe idea is that each developer maintains a base branch, all\ndependencies are merged into that base branch\nand all their work is performed ontop of that base. As the work is\nstabilised, it is rebased onto topic branches based\non well known tags and these topics are then published. The basic\nideas is always merge into the _base_ of the working branch\n, never merge into the _tip_  and never publish the tip of the working branch.\n\njon.\n"},{"id":"149901","messageId":"AANLkTikdi2-eM5VMq4cgoTGTB4i0i=i7=3Co10FxYy7k@mail.gmail.com","threadId":"24973","inReplyTo":"AANLkTikT6R4-HMLNebwwsF0pxP_uBTdi=+QkAL2m1EL=@mail.gmail.com","subject":"Re: Workflow question: Topic -> Next w/ frequent API changes","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-09-04T23:54:28Z","receivedAt":"2010-09-04T23:54:28Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"> The idea is that each developer maintains a base branch, all\n> dependencies are merged into that base branch\n> and all their work is performed ontop of that base. As the work is\n> stabilised, it is rebased onto topic branches based\n> on well known tags and these topics are then published. The basic\n> ideas is always merge into the _base_ of the working branch\n> , never merge into the _tip_  and never publish the tip of the working branch.\n>\n\nA key point I missed here that is worth emphasising - as work is\nrebased from the tip of the working branch onto stable topics that are\nthen published, the topics are then re-merged into the _base_ of the\nworking branch as well. This is very important - it keeps the working\ntree stable, while keeping the topic branches clean.\n\n> jon.\n>\n"}]}