{"thread":{"id":"23645","subject":"Integration-Manager Workflow and merges","startedAt":"2010-05-01T00:02:41Z","lastAt":"2010-05-01T04:44:09Z","messageCount":3,"participants":["Sebastian Andres Mancilla Matta","Dmitrijs Ledkovs"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140664","messageId":"4BDB6FA1.4070802@alumnos.inf.utfsm.cl","threadId":"23645","inReplyTo":null,"subject":"Integration-Manager Workflow and merges","fromName":"Sebastian Andres Mancilla Matta","fromEmail":"smancill@alumnos.inf.utfsm.cl","sentAt":"2010-05-01T00:02:41Z","receivedAt":"2010-05-01T00:02:41Z","isPatch":false,"sender":{"key":"smancill@alumnos.inf.utfsm.cl","avatar":null},"body":"Hello.\n\nI am working with the Physics Department of my university, and I\nconvinced them to use Git for our project of particle analysis (all the\nphysicists work whit CVS or things like that, so I am very glad they\nliked Git and accepted it).\n\nSo, I am in charge of defining the workflow we are going to use (we are\na team of 6 to 10 developers). We will use two branches, the 'master'\nbranch has stable code, and all the work is done in the 'devel' branch.\n\nI want to use the Integration-Manager workflow, but I have some issues\nabout it. Suppose we have a blessed repository with the following state\nfor the 'devel' branch\n\n BLESSED (public)\n\n 1--2--3 devel\n\nand some developer (Dev1) has a clone of it, and his 'devel' branch and\nthe 'blessed/devel' branch point to the same commit\n\n DEVELOPER (private)\n\n 1--2--3 devel\n\nThis developer does some work and obtains\n\n DEVELOPER (private)\n\n 1---2---3 blesed/devel\n \\\n 4---5---6 devel\n\nbut in the meantime, other developer works on his own, and pushes their\nchanges to his public repository, and the maintainer accepts them and\npushes them to the blessed repository:\n\n BLESSED (public)\n\n 1---2---3---7---8 devel\n\nNow Dev1 pushes his changes to his public repository and sends a pull\nrequest to the maintainer. To this point, everything is fine.\n\nLater, Dev1 wants to continue his works, but he needs the changes made\nby the other developer. So, he fetches the blessed repository\n\n DEVELOPER (private)\n\n 1---2---3---7---8 blessed/devel\n \\\n 4---5---6 devel\n\nbut the maintainer has not accepted his changes yet, so blessed/devel's\ntip does not include public devel's tip of Dev1. The developer decides\nto merge 'blessed/devel', and work from that commit, and obtains\n\n DEVELOPER (private)\n\n 1---2---3-------7---8 blessed/devel\n \\ \\\n \\ 9---10---11 devel\n \\ /\n 4---5---6 origin/devel\n\nwith the commit 9 being the merge commit. In the meantime, the\nmaintainer sees the pull request of Dev1, and pulls his changes and\naccepts them, and updates the blessed repository\n\n BLESSED (public)\n\n 1---2---3---7---8---12 devel\n \\ /\n 4---5---6\n\nwith the commit 12 being the maintainer merge commit.\n\nAnd this is my problem. We have two differents commits (9 and 12) doing\nthe same thing. If Dev1 pushes his changes again, and sends a new pull\nrequest, what will be the state of the repository? I think it\nwill look like this at the end\n\n 1---2---3-----7----8--12-----------13 devel\n \\ \\/ /\n \\ /\\ /\n 4---5---6--9---10---11\n\nbut the history is a mess with those two merges doing the same. And this\nis only with one developer doing a merge. If all the others do the same,\nit will become a pain.\n\n\nCan you help me with some guidelines to solve this? We do not want to\nkeep a linear history doing rebase every time. We just want to avoid\nthose duplicated merges. I have been looking for similar workflows but\nthere is no useful information, or at least I have not found it.\n\n\nI think the solution is to forbid developers doing merges in the 'devel'\nbranch. Only the maintainer merges remotes branches. So the merge is\ndone in a temporal branch, and the work is done in a topic branch\n\n DEVELOPER (private)\n\n 1---2---3-----7-----8 blessed/devel\n \\ \\\n 4---5---6 \\ devel\n \\ \\\n ----9 tmpMerge\n \\\n 10---11 topic\n\nthen, after the maintainer accepted the first pull request, Dev1 fetches\nthe blessed repository, obtaining the merge commit 12. Then he merges \nthe branch 'blessed/devel' into his 'devel' branch (this is just a\nfast-forward merge)\n\n DEVELOPER (private)\n\n 1---2---3-----7----8--12 devel - blessed/devel\n \\ \\/\n \\ /\\\n 4---5---6--9 tmpMerge\n \\\n 10---11 topic\n\nand finally he rebases the 'topic' branch onto 'devel'\n\n DEVELOPER (private)\n\n 1---2---3---7---8---12 blessed/devel\n \\ / \\\n 4---5---6 20---21 devel\n\nand pushes his work and sends a pull request to the maintainer. For\nboth, the maintainer and the developer, the repository looks like this\nat the end (after the maintainer accepts Dev1's changes)\n\n 1---2---3---7---8---12---20---21 devel\n \\ /\n 4---5---6\n\nThis way, there is no duplicated merges. Is this a good workflow? Can\nanyone using a similar approach give me some comments?\n\nThanks.\n\n\n-- \nSebastian Mancilla Matta\nEst. Ingenieria Civil Informatica UTFSM\nValparaiso - Chile\n"},{"id":"140672","messageId":"y2g86ecb3c71004302140p43c2a778xe3015192e5227dae@mail.gmail.com","threadId":"23645","inReplyTo":"4BDB6FA1.4070802@alumnos.inf.utfsm.cl","subject":"Re: Integration-Manager Workflow and merges","fromName":"Dmitrijs Ledkovs","fromEmail":"dmitrij.ledkov@ubuntu.com","sentAt":"2010-05-01T04:40:20Z","receivedAt":"2010-05-01T04:40:20Z","isPatch":false,"sender":{"key":"dmitrij.ledkov@ubuntu.com","avatar":"https://gravatar.com/avatar/79b618c6eb391ddb486c2ee0d3b429014e0e9ba579fd55f2e035f482fc8c24f4?d=mp&s=160"},"body":"On 1 May 2010 01:02, Sebastian Andres Mancilla Matta\n wrote:\n> And this is my problem. We have two differents commits (9 and 12) doing\n> the same thing. If Dev1 pushes his changes again, and sends a new pull\n> request, what will be the state of the repository? I think it\n> will look like this at the end\n>\n>        1---2---3-----7----8--12-----------13   devel\n>                 \\          \\/            /\n>                  \\         /\\           /\n>                   4---5---6--9---10---11\n>\n> but the history is a mess with those two merges doing the same. And this\n> is only with one developer doing a merge. If all the others do the same,\n> it will become a pain.\n>\n>\n\nAs far as I know git will not do a second same merge.\n\nI'm not good at these but IMHO commit 10 will be a criss-cross merge\nof just 9 & (8,12). Git knows that it has commit 7 in the branch with\ntip 11.\n\nTry out this on the command-line and notice which parents are listed\nin the $git log or use gitk to see how git merged stuff. Also run gitk\non large compex repositories to see how all the different merges get\ndone.\n\nHistory is a mess by definition =) git doesn't care or assume that any\nbranch is more important than the other ;-)\n\nI don't understand what kind of pain does this cause? doing $ git log\ndevel..HEAD will show you just the outstanding commit Nr11 =)\n\nWith regards,\n\nDmitrijs.\n"},{"id":"140671","messageId":"p2u86ecb3c71004302144w942be5f6p9ce8f431653338f7@mail.gmail.com","threadId":"23645","inReplyTo":"4BDB6FA1.4070802@alumnos.inf.utfsm.cl","subject":"Re: Integration-Manager Workflow and merges","fromName":"Dmitrijs Ledkovs","fromEmail":"dmitrij.ledkov@ubuntu.com","sentAt":"2010-05-01T04:44:09Z","receivedAt":"2010-05-01T04:44:09Z","isPatch":false,"sender":{"key":"dmitrij.ledkov@ubuntu.com","avatar":"https://gravatar.com/avatar/79b618c6eb391ddb486c2ee0d3b429014e0e9ba579fd55f2e035f482fc8c24f4?d=mp&s=160"},"body":"On 1 May 2010 01:02, Sebastian Andres Mancilla Matta\n wrote:\n>\n> This way, there is no duplicated merges. Is this a good workflow? Can\n> anyone using a similar approach give me some comments?\n>\n> Thanks.\n>\n\nDon't worry about duplicate merges. Allow everyone to pull from each other =)\n\nThe \"duplicate\" merge will not make you to resolve the same conflicts\nagain if you are worried about that.\n"}]}