{"thread":{"id":"20962","subject":"git workflow for fully distributed mini-teams","startedAt":"2009-09-16T07:35:05Z","lastAt":"2009-09-18T07:01:22Z","messageCount":8,"participants":["Rustom Mody","Nicolas Sebrecht","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"123305","messageId":"f46c52560909160035o6b09800eh5219d49e7569cf23@mail.gmail.com","threadId":"20962","inReplyTo":null,"subject":"git workflow for fully distributed mini-teams","fromName":"Rustom Mody","fromEmail":"rustompmody@gmail.com","sentAt":"2009-09-16T07:35:05Z","receivedAt":"2009-09-16T07:35:05Z","isPatch":false,"sender":{"key":"rustompmody@gmail.com","avatar":null},"body":"I am trying to formulate (and understand) what it means to have a\nfully-distributed mini team workflow with git.\n\nBy fully distributed I mean theres no central repo -- not for pushing\nor even pulling; all communication is by email.\nBy mini-team I mean: Not more than 5 programmers.\n\nHeres a typical scenario.\n\nThere are 3 programmers A B and C who communicate by email who have\nstarted off from the same code base.\n\nA's branches: dev, master, B, C\nB's branches: dev, master, A, C\nC's branches: dev, master, A, B\n\nA's best practices (and invariants) are:\nI (ie A) develop on dev (or other topic branches).\nI only merge onto master; never commit.\nI never work on nor merge onto B and C.\nWhen B sends me patches I apply them to the B branch likewise for C.\nThereafter I merge that branch onto dev or master.\nThere are no tracking branches because there are no remotes -- no\ncentral repo. [not clear about this]\n\nB and C have corresponding practices/behavior.\n\nSo the questions...\n\nIs there a better way of doing things?\nCan some of these practices/invariants be enforced by scripts/options etc?\nWhat about checkpointing and restoring from botches?\n"},{"id":"123359","messageId":"20090916164356.GB24893@vidovic","threadId":"20962","inReplyTo":"f46c52560909160035o6b09800eh5219d49e7569cf23@mail.gmail.com","subject":"Re: git workflow for fully distributed mini-teams","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2009-09-16T16:43:56Z","receivedAt":"2009-09-16T16:43:56Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 16/09/09, Rustom Mody wrote:\n> \n> A's best practices (and invariants) are:\n> I (ie A) develop on dev (or other topic branches).\n> I only merge onto master; never commit.\n> I never work on nor merge onto B and C.\n> When B sends me patches I apply them to the B branch likewise for C.\n> Thereafter I merge that branch onto dev or master.\n> There are no tracking branches because there are no remotes -- no\n> central repo. [not clear about this]\n> \n> B and C have corresponding practices/behavior.\n> \n> So the questions...\n> \n> Is there a better way of doing things?\n> Can some of these practices/invariants be enforced by scripts/options etc?\n\nWhat's may be hard here is about \"releasing topic\". With a \"maintainer\noriented workflow\", the status of each topic is clear (either \"won't\nmerge as is, needs more work\" or \"should be good enough, is merged and\naims to be in the next release\").\n\nIn the fully-distributed workflow you describe, the state of the topics\nlooks hard to know. Who releases what is not clear.\n\nAlso, I see a duplication of the same work for all the developers in a\nteam: \"merge my topics with topics from others\". This could be solved\nwith one more common repository wich could stand as a \"virtual\nmaintainer repository\" where each developer could release any topic.\nTopics that don't need any more work would have to be merged in a\ndedicated public branch (\"next\"?) for testing, and topics that aren't\ngood enough into another dedicated branch (\"pu\"?). So, each developer\nwould have to push publishable merges into this repository. This way,\neveryone could use the merges done by another developer (by doing a\nfetch and rebasing of his current work on top of it).\n\nNotice that this is all about \"everybody uses the same base for his\ncurrent work\" (to avoid per-developer scratch on merges) and \"don't let\neveryone do the same work on his own\" (to avoid duplicate work).\n\n> What about checkpointing and restoring from botches?\n\nI think this is be easily doable (against your described workflow) with\ngood conventions in branch names. Topics like \"pending-topicA\",\n\"pending-topicB\", etc that would have to be merged (using a script) into\na \"all pending topics\" branch should do what you want, no? Restoring\nfrom botches would mean removing the crappy branch and re-execute the\nscript.\n\nHope this helps.\n\n-- \nNicolas Sebrecht\n"},{"id":"123412","messageId":"f46c52560909170003l61a2e1a3kf62c94ffd7ed9710@mail.gmail.com","threadId":"20962","inReplyTo":"20090916164356.GB24893@vidovic","subject":"Re: git workflow for fully distributed mini-teams","fromName":"Rustom Mody","fromEmail":"rustompmody@gmail.com","sentAt":"2009-09-17T07:03:49Z","receivedAt":"2009-09-17T07:03:49Z","isPatch":false,"sender":{"key":"rustompmody@gmail.com","avatar":null},"body":"Rustom Mody wrote:\n> By fully distributed I mean theres no central repo -- not for pushing\n> or even pulling; all communication is by email.\n> By mini-team I mean: Not more than 5 programmers.\n\nOn Wed, Sep 16, 2009 at 10:13 PM, Nicolas Sebrecht wrote:\n>\n>\n> Also, I see a duplication of the same work for all the developers in a\n> team: \"merge my topics with topics from others\". This could be solved\n> with one more common repository wich could stand as a \"virtual\n> maintainer repository\" where each developer could release any topic.\n> Topics that don't need any more work would have to be merged in a\n> dedicated public branch (\"next\"?) for testing, and topics that aren't\n> good enough into another dedicated branch (\"pu\"?). So, each developer\n> would have to push publishable merges into this repository. This way,\n> everyone could use the merges done by another developer (by doing a\n> fetch and rebasing of his current work on top of it).\n\nPush? Fetch? How without a common repo? [Sorry if this is totally noob!]\n>\n> Notice that this is all about \"everybody uses the same base for his\n> current work\" (to avoid per-developer scratch on merges) and \"don't let\n> everyone do the same work on his own\" (to avoid duplicate work).\n>\n>> What about checkpointing and restoring from botches?\n>\n> I think this is be easily doable (against your described workflow) with\n> good conventions in branch names. Topics like \"pending-topicA\",\n> \"pending-topicB\", etc that would have to be merged (using a script) into\n> a \"all pending topics\" branch should do what you want, no?  Restoring\n> from botches would mean removing the crappy branch and re-execute the\n> script.\n\nI am really concerned about things like:\n\nA commited something on the B branch, received a patch from B. That\npatch did not apply (or worse it applied -- on top of A's!)\nSo ideally there should be an option that says (when A is on B branch\nand tries to commit) \"Sorry buddy -- No commits here!\"\n"},{"id":"123420","messageId":"4AB1E514.9030501@viscovery.net","threadId":"20962","inReplyTo":"f46c52560909170003l61a2e1a3kf62c94ffd7ed9710@mail.gmail.com","subject":"Re: git workflow for fully distributed mini-teams","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-09-17T07:28:20Z","receivedAt":"2009-09-17T07:28:20Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Rustom Mody schrieb:\n> I am really concerned about things like:\n> \n> A commited something on the B branch, received a patch from B. That\n> patch did not apply (or worse it applied -- on top of A's!)\n> So ideally there should be an option that says (when A is on B branch\n> and tries to commit) \"Sorry buddy -- No commits here!\"\n\nI think the most important thing would be that you send bundles around,\nnot patches, so that you all can work with and talk about unique object names.\n\n-- Hannes\n"},{"id":"123443","messageId":"f46c52560909170538q4d316d00jcccad8ec9f563574@mail.gmail.com","threadId":"20962","inReplyTo":"4AB1E514.9030501@viscovery.net","subject":"Re: git workflow for fully distributed mini-teams","fromName":"Rustom Mody","fromEmail":"rustompmody@gmail.com","sentAt":"2009-09-17T12:38:20Z","receivedAt":"2009-09-17T12:38:20Z","isPatch":false,"sender":{"key":"rustompmody@gmail.com","avatar":null},"body":"On Thu, Sep 17, 2009 at 12:58 PM, Johannes Sixt wrote:\n> I think the most important thing would be that you send bundles around,\n> not patches, so that you all can work with and talk about unique object names.\n>\n> -- Hannes\n\nThats what we need -- thanks a 'bundle'!\n"},{"id":"123452","messageId":"f46c52560909170652t54f68c31hfbb8ae6472190ac1@mail.gmail.com","threadId":"20962","inReplyTo":"f46c52560909170538q4d316d00jcccad8ec9f563574@mail.gmail.com","subject":"Re: git workflow for fully distributed mini-teams","fromName":"Rustom Mody","fromEmail":"rustompmody@gmail.com","sentAt":"2009-09-17T13:52:23Z","receivedAt":"2009-09-17T13:52:23Z","isPatch":false,"sender":{"key":"rustompmody@gmail.com","avatar":null},"body":"On Thu, Sep 17, 2009 at 6:08 PM, Rustom Mody wrote:\n> On Thu, Sep 17, 2009 at 12:58 PM, Johannes Sixt wrote:\n>> I think the most important thing would be that you send bundles around,\n>> not patches, so that you all can work with and talk about unique object names.\n>>\n>> -- Hannes\n\nI started looking at git bundle and find things like master\\~10.\nWhats the backslash doing?\n\nTried running git bundle create with and without the backslash -- it\nproduced the same bundle.\n\nLooked up tilde-expansion in bash and I gather bash does things to the\n~ only on beginning of words whereas as far as I can see git uses ~\nonly at the end of words like master.\n\nWhat am I missing?\n"},{"id":"123454","messageId":"4AB24C06.5030207@viscovery.net","threadId":"20962","inReplyTo":"f46c52560909170652t54f68c31hfbb8ae6472190ac1@mail.gmail.com","subject":"Re: git workflow for fully distributed mini-teams","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-09-17T14:47:34Z","receivedAt":"2009-09-17T14:47:34Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"[On this list, we reply to all, so that the Cc list remains]\n\nRustom Mody schrieb:\n> I started looking at git bundle and find things like master\\~10.\n> Whats the backslash doing?\n\nIt's intended as markup for the pipeline that generates the documentation\nfrom git-bundle.txt. Either the markup is incorrect, or there is a bug in\nthe pipeline, because I only see it in the generated HTML. Ignore it.\n\n-- Hannes\n"},{"id":"123483","messageId":"f46c52560909180001r2a4e58aaxfdea136784431139@mail.gmail.com","threadId":"20962","inReplyTo":"4AB24C06.5030207@viscovery.net","subject":"Re: git workflow for fully distributed mini-teams","fromName":"Rustom Mody","fromEmail":"rustompmody@gmail.com","sentAt":"2009-09-18T07:01:22Z","receivedAt":"2009-09-18T07:01:22Z","isPatch":false,"sender":{"key":"rustompmody@gmail.com","avatar":null},"body":"On Thu, Sep 17, 2009 at 8:17 PM, Johannes Sixt wrote:\n> [On this list, we reply to all, so that the Cc list remains]\n>\n> Rustom Mody schrieb:\n>> I started looking at git bundle and find things like master\\~10.\n>> Whats the backslash doing?\n>\n> It's intended as markup for the pipeline that generates the documentation\n> from git-bundle.txt. Either the markup is incorrect, or there is a bug in\n> the pipeline, because I only see it in the generated HTML. Ignore it.\n\nSeems to be there in my git-bundle.txt as well as git-bundle.html.\nSo its probably the markup not the pipeline.\n"}]}