{"thread":{"id":"17077","subject":"Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?","startedAt":"2009-01-10T11:11:54Z","lastAt":"2009-01-10T16:29:43Z","messageCount":5,"participants":["Junichi Uekawa","Peter Harris","Santi Béjar","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"99883","messageId":"87vdsntnyd.dancerj%dancer@netfort.gr.jp","threadId":"17077","inReplyTo":null,"subject":"Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?","fromName":"Junichi Uekawa","fromEmail":"dancer@netfort.gr.jp","sentAt":"2009-01-10T11:11:54Z","receivedAt":"2009-01-10T11:11:54Z","isPatch":false,"sender":{"key":"dancer@netfort.gr.jp","avatar":null},"body":"Hi,\n\nI've been maintaining my Git repository (monthlyreport.git) where most\npeople do not have push access, and I'm taking patches through e-mail\nwith 'git am'.\n\nIt often happens that I'm receiving patches which won't apply without\na merge ('git am -3') and happen to be conflict-resolving often,\nbecause people work off a branch a few days before, and try to send\npatches nearer the deadline (This is a monthly meeting resume, which\npeople are expected to submit their material, so this is kind of\nnormal).\n\n\nOne thing I'm worried is that users apparently have to throw away\ntheir own change or do some conflict resolution.\n\n\nUser does \n git pull xxxx\n edit ...\n git add \n git commit \n git format-patch -o ... HEAD^\n\n\nI do bunch of \n git am -3 (which usually has a conflict of some way or other)\n git add XXXX\n git am -3 --resolve\n git push\n\n\nUser then find that when doing\n\n git pull\n\nagain, a conflict will occur. \n\n\n\nI am thinking of recommending the users to create a branch\n\n git checkout -b my-work-for-2009-01 origin\n edit ...\n git add\n git commit\n git format-patch -o ... HEAD^\n send the email\n\nand do\n\n git checkout master \n git pull\n\nand throw away their branches when they are included upstream.\n\n\n\nSomething tells me the problem is that I'm probably using a workflow\nthat resembles SVN too much, and users aren't used to branches yet.\nHas anybody found this to be a problem, or better yet, is there a \nbetter workflow?\n\n\n\n-- \ndancer@{netfort.gr.jp,debian.org}\n"},{"id":"99896","messageId":"eaa105840901100647y70b53ae0w495af69b7281cae7@mail.gmail.com","threadId":"17077","inReplyTo":"87vdsntnyd.dancerj%dancer@netfort.gr.jp","subject":"Re: Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-01-10T14:47:17Z","receivedAt":"2009-01-10T14:47:17Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Sat, Jan 10, 2009 at 6:11 AM, Junichi Uekawa wrote:\n> I am thinking of recommending the users to create a branch\n...\n> and throw away their branches when they are included upstream.\n\nYes, with a patch based workflow, this is almost required; all of the\ncommits will at least have different committer information.\n\nThere's nothing wrong with this approach.\n\n> Something tells me the problem is that I'm probably using a workflow\n> that resembles SVN too much, and users aren't used to branches yet.\n> Has anybody found this to be a problem, or better yet, is there a\n> better workflow?\n\nIf you need the commits to be identical, and you don't mind your email\nconsisting of a binary blob attachment, you can ask your contributors\nto send you a bundle instead of a series of patches. \"git help bundle\"\nfor details.\n\nPeter Harris\n"},{"id":"99898","messageId":"adf1fd3d0901100647wd66a57bufb42d3d7d415e76d@mail.gmail.com","threadId":"17077","inReplyTo":"87vdsntnyd.dancerj%dancer@netfort.gr.jp","subject":"Re: Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2009-01-10T14:47:48Z","receivedAt":"2009-01-10T14:47:48Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"2009/1/10 Junichi Uekawa :\n> Hi,\n>\n> I've been maintaining my Git repository (monthlyreport.git) where most\n> people do not have push access, and I'm taking patches through e-mail\n> with 'git am'.\n>\n> It often happens that I'm receiving patches which won't apply without\n> a merge ('git am -3') and happen to be conflict-resolving often,\n> because people work off a branch a few days before, and try to send\n> patches nearer the deadline (This is a monthly meeting resume, which\n> people are expected to submit their material, so this is kind of\n> normal).\n>\n>\n> One thing I'm worried is that users apparently have to throw away\n> their own change or do some conflict resolution.\n>\n>\n> User does\n> git pull xxxx\n> edit ...\n> git add\n> git commit\n> git format-patch -o ... HEAD^\n>\n>\n> I do bunch of\n> git am -3 (which usually has a conflict of some way or other)\n> git add XXXX\n> git am -3 --resolve\n> git push\n>\n>\n> User then find that when doing\n>\n> git pull\n>\n> again, a conflict will occur.\n>\n>\n>\n> I am thinking of recommending the users to create a branch\n>\n> git checkout -b my-work-for-2009-01 origin\n> edit ...\n> git add\n> git commit\n> git format-patch -o ... HEAD^\n> send the email\n>\n> and do\n>\n> git checkout master\n> git pull\n>\n> and throw away their branches when they are included upstream.\n>\n>\n>\n> Something tells me the problem is that I'm probably using a workflow\n> that resembles SVN too much, and users aren't used to branches yet.\n> Has anybody found this to be a problem, or better yet, is there a\n> better workflow?\n\nI think your workflow is fine. When someone sends a patch s/he has to\nknow that their branch is a throw away branch to create the patch.\nAnother thing is if you send it as a public repository or as a bundle,\nand even then the maintainer can decide to apply it merging or\ncherry-picking.\n\nThere is a doc explaining \" An overview of recommended workflows with\ngit\" in git:\n\nhttp://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html\n\nHTH,\nSanti\n"},{"id":"99905","messageId":"slrngmhijb.3u7.sitaramc@sitaramc.homelinux.net","threadId":"17077","inReplyTo":"87vdsntnyd.dancerj%dancer@netfort.gr.jp","subject":"Re: Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-10T16:18:52Z","receivedAt":"2009-01-10T16:18:52Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-10, Junichi Uekawa wrote:\n\n> I've been maintaining my Git repository (monthlyreport.git) where most\n> people do not have push access, and I'm taking patches through e-mail\n> with 'git am'.\n\nIn general, if inputs are bunched up and arrive all\ntogether, there's bound to be conflicts.\n\n> It often happens that I'm receiving patches which won't apply without\n> a merge ('git am -3') and happen to be conflict-resolving often,\n> because people work off a branch a few days before, and try to send\n\nThat's the key phrase, the delay between when they pulled\nand when they committed. I'm not sure of the nature of the\ndata, and how close it is to \"source code\" but normally this\nis a case for a rebase.\n\nIf you don't want them to use branches, you can sort of get\naway with these changes to your current flow:\n\n> User does \n> git pull xxxx\n use \"git pull --rebase xxxx\" instead of plain pull;\n resolve conflicts if needed\n> edit ...\n (I'm assuming there's a long gap between the pull above\n and the add below)\n> git add \n> git commit \n git fetch # update from origin\n git rebase origin/master\n (they may have to resolve conflicts, but it's easiest\n when done at this point)\n> git format-patch -o ... HEAD^\n\n> I do bunch of \n> git am -3 (which usually has a conflict of some way or other)\n> git add XXXX\n> git am -3 --resolve\n> git push\n\nThe less the time gap between their \"git format-patch\" and\nyour \"git am\", the less conflicts you will have. If you're\nworking almost in \"real time\", the next user gets the latest\ntree when he does his \"git rebase origin/master\" -- and in\nfact that becomes pretty much the only point at which any\nconflicts even happen.\n\n...and you don't usually have to resolve a single conflict\n;-)\n"},{"id":"99906","messageId":"slrngmhj7n.4nl.sitaramc@sitaramc.homelinux.net","threadId":"17077","inReplyTo":"eaa105840901100647y70b53ae0w495af69b7281cae7@mail.gmail.com","subject":"Re: Main branch being maintained with 'git am', how do mere mortals interact without too much conflicts?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-10T16:29:43Z","receivedAt":"2009-01-10T16:29:43Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-10, Peter Harris wrote:\n> On Sat, Jan 10, 2009 at 6:11 AM, Junichi Uekawa wrote:\n>> I am thinking of recommending the users to create a branch\n> ...\n>> and throw away their branches when they are included upstream.\n>\n> Yes, with a patch based workflow, this is almost required; all of the\n> commits will at least have different committer information.\n>\n> There's nothing wrong with this approach.\n\nThat is almost exactly what a rebase does. Each patch on\nyour local \"master\" that eventually made it upstream gets\ndiscarded during the rebase (which is a pretty cool thing!),\nand what remains are commits that did not make it upstream\n-- their current \"work in progress\".\n\nThe difference between \"origin/master\" and \"master\", after\neach rebase, is their \"private branch\".\n\nExcept you don't have to confuse them by saying so ;-)\n\n>> Something tells me the problem is that I'm probably using a workflow\n>> that resembles SVN too much, and users aren't used to branches yet.\n>> Has anybody found this to be a problem, or better yet, is there a\n>> better workflow?\n>\n> If you need the commits to be identical, and you don't mind your email\n> consisting of a binary blob attachment, you can ask your contributors\n> to send you a bundle instead of a series of patches. \"git help bundle\"\n> for details.\n\nExcellent idea. But it only works for the first user who\nsends him a bundle. The next one that he gets, assuming\nthat user also started from the same \"upstream\" commit as\nthe starting point, will be a merge, and he has to resolve\nconflicts anyway.\n\nEssentially, two things have to happen to reduce conflict\nresolution overall. The users must rebase against the\nlatest upstream before sending the patch, and the supervisor\nmust process and push received patches asap.\n"}]}