{"thread":{"id":"20113","subject":"Dividing up a large merge.","startedAt":"2009-07-14T23:32:46Z","lastAt":"2009-07-15T21:01:13Z","messageCount":13,"participants":["davidb@quicinc.com","Bryan Donlan","Avery Pennarun","Douglas Campos","Theodore Tso","Jakub Narebski","Larry D'Anna","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"117989","messageId":"20090714233246.GA25390@huya.quicinc.com","threadId":"20113","inReplyTo":null,"subject":"Dividing up a large merge.","fromName":"","fromEmail":"davidb@quicinc.com","sentAt":"2009-07-14T23:32:46Z","receivedAt":"2009-07-14T23:32:46Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"I'm trying to figure out a better way of dividing up the effort\ninvolved in a merge amongst a group of people.  Right now, I\nbasically describe the merge to each of them, and ask them to\nmerge their part, and then 'git checkout HEAD' the other parts.\nThey tell me about the commits, along with the files that they've\nmerged correctly.  When everybody is done, I make a real merge\ncommit, and pull in all of their files.  It's a lot for me to\ntrack, and confusing for each person.\n\nI'd like to create a branch we can all push to that we gradually\nwork to become the result of a resolved merge.  Not only does git\nnot want to help me do the merge, but seems to actively be\nfighting against me doing this.\n\nWhat I thought of was something like telling people to do:\n\n  $ git merge v2.6.30\n  resolve some files\n  $ git checkout HEAD ...rest of files...\n  $ git commit; git push\n\nbut that 'rest of files' is fairly large and complicated.  I can\nthink of two ideas:\n\n  - Something that basically does a partial 'git reset --hard\n    HEAD' to put many of the files back.\n\n  - The ability to specify subpaths on the 'git merge' to do the\n    merge work but limited to a directory or set of files.\n\nObviously, either case will require someone to still track the\noverall effort and make sure the final state of the tree really\nrepresents the total merge.\n\nIs there anything that can parse the output of 'git merge-tree'?\nEven just splitting this up and then applying parts of it would\nbe helpful.  Would it be useful to write something that can apply\nthe results output of 'git merge-tree'?\n\nThanks,\nDavid\n"},{"id":"117990","messageId":"3e8340490907141716j77df346es1f894d6a7f6cb0aa@mail.gmail.com","threadId":"20113","inReplyTo":"20090714233246.GA25390@huya.quicinc.com","subject":"Re: Dividing up a large merge.","fromName":"Bryan Donlan","fromEmail":"bdonlan@gmail.com","sentAt":"2009-07-15T00:16:54Z","receivedAt":"2009-07-15T00:16:54Z","isPatch":false,"sender":{"key":"bdonlan@gmail.com","avatar":null},"body":"On Tue, Jul 14, 2009 at 7:32 PM, <davidb@quicinc.com> wrote:\n> I'm trying to figure out a better way of dividing up the effort\n> involved in a merge amongst a group of people.  Right now, I\n> basically describe the merge to each of them, and ask them to\n> merge their part, and then 'git checkout HEAD' the other parts.\n> They tell me about the commits, along with the files that they've\n> merged correctly.  When everybody is done, I make a real merge\n> commit, and pull in all of their files.  It's a lot for me to\n> track, and confusing for each person.\n\nWhat do you mean by describing a merge? git is designed to have all\nthe information needed for a merge inherent in the repository history.\n\n> I'd like to create a branch we can all push to that we gradually\n> work to become the result of a resolved merge.  Not only does git\n> not want to help me do the merge, but seems to actively be\n> fighting against me doing this.\n>\n> What I thought of was something like telling people to do:\n>\n>  $ git merge v2.6.30\n>  resolve some files\n>  $ git checkout HEAD ...rest of files...\n>  $ git commit; git push\n>\n> but that 'rest of files' is fairly large and complicated.  I can\n> think of two ideas:\n>\n>  - Something that basically does a partial 'git reset --hard\n>    HEAD' to put many of the files back.\n>\n>  - The ability to specify subpaths on the 'git merge' to do the\n>    merge work but limited to a directory or set of files.\n>\n> Obviously, either case will require someone to still track the\n> overall effort and make sure the final state of the tree really\n> represents the total merge.\n>\n> Is there anything that can parse the output of 'git merge-tree'?\n> Even just splitting this up and then applying parts of it would\n> be helpful.  Would it be useful to write something that can apply\n> the results output of 'git merge-tree'?\n\nI'm having a hard time understanding the situation here - why can't you just:\n$ git checkout -b mergebranch v2.6.30\n$ git merge developer1/topic\n# Fix conflicts\n$ git merge developer2/topic\n# Fix conflicts\n# etc\n\nWhy are there so many conflicts to make this an issue?\n\nIf the commits are isolated to small changes, rebasing the developer\ntopic branches instead of merging may help, by allowing you to take\nconflicts one commit at a time. For example, if your problems are\nprimarily conflicts between developer branches and upstream:\n\n$ git checkout -b mergebranch-dev1 developer1/topic\n$ git rebase v2.6.30\n# Fix conflicts on a commit-by-commit basis\n$ git checkout -b mergebranch-dev2 developer2/topic\n$ git rebase v2.6.30\n# Fix conflicts on a commit-by-commit basis\n$ git checkout -b mergebranch\n$ git merge mergebranch-dev1\n# Fix any remaining conflicts\n\nIf your problems are because of conflicts between developer branches\nand each other:\n$ git checkout -b mergebranch-dev1 developer1/topic\n$ git rebase v2.6.30\n# Fix conflicts on a commit-by-commit basis\n$ git checkout -b mergebranch-dev2 developer2/topic\n$ git rebase mergebranch-dev1\n# Fix conflicts on a commit-by-commit basis\n\nThese rebasing approaches will change the commit IDs, so your\ndevelopers will need to rebase any further work upon these new commit\nIDs, but if things are as bad as you say, a commit-by-commit merge\nthat rebase allows you may be much simpler.\n"},{"id":"117991","messageId":"20090715002926.GA26630@huya.quicinc.com","threadId":"20113","inReplyTo":"3e8340490907141716j77df346es1f894d6a7f6cb0aa@mail.gmail.com","subject":"Re: Dividing up a large merge.","fromName":"","fromEmail":"davidb@quicinc.com","sentAt":"2009-07-15T00:29:26Z","receivedAt":"2009-07-15T00:29:26Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Tue, Jul 14, 2009 at 05:16:54PM -0700, Bryan Donlan wrote:\n\n> What do you mean by describing a merge? git is designed to have all\n> the information needed for a merge inherent in the repository history.\n\nYes, provided you can actually do the merge all at once.\n\n> Why are there so many conflicts to make this an issue?\n\nBecause I have to work in the \"real world\".\n\n> If the commits are isolated to small changes, rebasing the developer\n> topic branches instead of merging may help, by allowing you to take\n> conflicts one commit at a time. For example, if your problems are\n> primarily conflicts between developer branches and upstream:\n\nNo real developer branches with conflicts (I make those be\nfixed), but several upstreams.  We have many developers busily\ndoing work, and one or more other companies is also working on\nthe same code.  Meanwhile, the mainline kernel advances at it's\nown astounding rate.\n\nUnfortunately, paying customers will always get priority of work,\neven when that position is actually somewhat shortsighted and it\nmakes for a lot of merge effort later.\n\nThe real issue is that there isn't any single individual who\nunderstands all of the code that conflicts.  It has to be divided\nup somehow, I'm just trying to figure out a better way of doing\nit.\n\nThanks,\nDavid\n"},{"id":"117992","messageId":"32541b130907141734o59d224i7e0f39aa8a85e8ef@mail.gmail.com","threadId":"20113","inReplyTo":"20090715002926.GA26630@huya.quicinc.com","subject":"Re: Dividing up a large merge.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-07-15T00:34:26Z","receivedAt":"2009-07-15T00:34:26Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Jul 14, 2009 at 8:29 PM, <davidb@quicinc.com> wrote:\n> The real issue is that there isn't any single individual who\n> understands all of the code that conflicts.  It has to be divided\n> up somehow, I'm just trying to figure out a better way of doing\n> it.\n\nHow about having one person do the merge, then commit it (including\nconflict markers), then have other people just make a series of\ncommits removing the conflict markers?\n\nAvery\n"},{"id":"117994","messageId":"20090715011914.GA17100@huya.quicinc.com","threadId":"20113","inReplyTo":"32541b130907141734o59d224i7e0f39aa8a85e8ef@mail.gmail.com","subject":"Re: Dividing up a large merge.","fromName":"","fromEmail":"davidb@quicinc.com","sentAt":"2009-07-15T01:19:14Z","receivedAt":"2009-07-15T01:19:14Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Tue, Jul 14, 2009 at 05:34:26PM -0700, Avery Pennarun wrote:\n\n> How about having one person do the merge, then commit it (including\n> conflict markers), then have other people just make a series of\n> commits removing the conflict markers?\n\nI guess this helps in some sense, but the intermediate result\nisn't going to build, and things like mergetool aren't going to\nwork.  It's helpful for the individuals to have the full merge\nconflict available, or at least the stages of the files in\nquestion.\n\nDavid\n"},{"id":"117995","messageId":"ed88cb980907141829p44bd616ete74ec02cfad76345@mail.gmail.com","threadId":"20113","inReplyTo":"20090715011914.GA17100@huya.quicinc.com","subject":"Re: Dividing up a large merge.","fromName":"Douglas Campos","fromEmail":"douglas@theros.info","sentAt":"2009-07-15T01:29:03Z","receivedAt":"2009-07-15T01:29:03Z","isPatch":false,"sender":{"key":"douglas@theros.info","avatar":"https://gravatar.com/avatar/bca8e0e43e860dab00ec17dd3f1b60df6af911655fae70a0bbdeebeb889de421?d=mp&s=160"},"body":"Merging the peer branches before doesn't help it?\n\nOn Tue, Jul 14, 2009 at 10:19 PM, <davidb@quicinc.com> wrote:\n> On Tue, Jul 14, 2009 at 05:34:26PM -0700, Avery Pennarun wrote:\n>\n>> How about having one person do the merge, then commit it (including\n>> conflict markers), then have other people just make a series of\n>> commits removing the conflict markers?\n>\n> I guess this helps in some sense, but the intermediate result\n> isn't going to build, and things like mergetool aren't going to\n> work.  It's helpful for the individuals to have the full merge\n> conflict available, or at least the stages of the files in\n> question.\n>\n> David\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\n\n\n-- \nDouglas Campos\nTheros Consulting\n+55 11 7626 5959\n+55 11 3020 8168\n"},{"id":"117996","messageId":"32541b130907141832r5217183wc6a0494d6d77bc06@mail.gmail.com","threadId":"20113","inReplyTo":"20090715011914.GA17100@huya.quicinc.com","subject":"Re: Dividing up a large merge.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-07-15T01:32:14Z","receivedAt":"2009-07-15T01:32:14Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Jul 14, 2009 at 9:19 PM, <davidb@quicinc.com> wrote:\n> On Tue, Jul 14, 2009 at 05:34:26PM -0700, Avery Pennarun wrote:\n>> How about having one person do the merge, then commit it (including\n>> conflict markers), then have other people just make a series of\n>> commits removing the conflict markers?\n>\n> I guess this helps in some sense, but the intermediate result\n> isn't going to build, and things like mergetool aren't going to\n> work.  It's helpful for the individuals to have the full merge\n> conflict available, or at least the stages of the files in\n> question.\n\nIt sounds like you're going in circles a bit here.  You want the full\nmerge conflict available - but you want it to be able to build.\n\nIt sounds like the \"git reset the unwanted subdirs\" solution suggested\nearlier is the only option that will really work.  You could simplify\nlife for your co-workers by writing a script to automate the steps, I\nsuppose.\n\nYou probably want all the individuals to use merge --squash, so that\nyou don't mark the history as merged until you're done.  Then you\ncombine all their work at the end and mark the commit as done using\n'git merge -s ours'.\n\nAvery\n"},{"id":"118017","messageId":"20090715122828.GA6570@mit.edu","threadId":"20113","inReplyTo":"20090715002926.GA26630@huya.quicinc.com","subject":"Re: Dividing up a large merge.","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2009-07-15T12:28:28Z","receivedAt":"2009-07-15T12:28:28Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Jul 14, 2009 at 05:29:26PM -0700, davidb@quicinc.com wrote:\n> No real developer branches with conflicts (I make those be\n> fixed), but several upstreams.  We have many developers busily\n> doing work, and one or more other companies is also working on\n> the same code.  Meanwhile, the mainline kernel advances at it's\n> own astounding rate.\n\nIf you hare maintaining a large number of changes over a long-term\n(which in the case of the kernel can be measured in a month or two),\nit's often much easier to maintain things as a series of patches.\n\nThat way you can merge each patch one at a time.\n\nIf you already have everything in a git tree, I'd suggest pulling it\napart into separate patches, by using \"git format-patch\".  Note that\nif you have multiple merges into tree, this will go much more smoothly\nif you can separate things into a single linear stream.\n\nThis is also a good reason why if you have partial work that is\ncomplete enough to be merged into mainline, it is ***much*** better to\ntry pushing patches to mainline earlier rather than later.  Waiting\nuntil you are 100% done and the work is completely certified involves\na large number of risks; for example, what if people complain about\nwork that was done early on?  Or if the design was fundamentally\nflawed from the get-go?  At the minimum, you will save a huge amount\nof effort if you post a request-for-comment version of the patches up\nfront.\n\nAnd, if you believe your release cycle is going to run for more than,\nsay, 2-3 months, I suggest that you keep things in a single linear\npatch stream.  You can keep the patch series under git control, and\nthen rebase periodically; I'd suggest rebasing once a mainline release\nhappens (i.e., when 2.6.X is released), and then again after most of\nthe major changes have been merged in and the tree has settled down\n(i.e., after 2.6.X-rc2 or 2.6.X-rc3).\n\n> The real issue is that there isn't any single individual who\n> understands all of the code that conflicts.  It has to be divided\n> up somehow, I'm just trying to figure out a better way of doing\n> it.\n\nYeah, that's another prime argument for maintaining your changes as a\npatch queue.  I use a combination of quilt plus git.  So the rebasing\nmethodology becomes:\n\n# pop all patches\nguilt pop -a\t\t\t\n# update the base of the patches\ngit pull origin\t\t\t\n# start trying to apply each of the patches, one at a time\n# next_patch:\nguilt push -a\n# when you get a failure, the push will stop and tell you it can't \n# apply a patch; so force apply the patch:\nguilt push -f\n# \n# this will leave some patch .rej files; resolve the patch failures\n# for all of the files.    Use \"git add\" once the patches have been resolved\n# also make sure that any files that were added by the patch that was \n# force applied are also manually marked as needing added using \"git add\".\n# Once you are sure the patch is properly merged, do this:\nguilt refresh --diffstat\n# Check the changes made to the patch; I normally create a symlink from\n# .git/patches/<work-branch-for-quilt> to patches in the top level, i.e.\n# \"ln -s .git/patches/master patches\"; if you can't remember the name of the\n# patch, you can get it via the command \"guilt applied | tail -1\"\n(cd patches; git diff name-of-patch)\n# now repeat with the next set of patches by going back to next_patch, above\n\nI normally keep an indication of the version that the patch series is\nbased upon via a comment in the first line of the series file, like\nthis: \"# BASE v2.6.30-rc3\" or sometimes like this \"# BASE 6ab2792\".\nThis can be useful when creating automated scripts to test the patch\nseries, since they know what version to apply the patches against.\n\nIn your case, the first person to start the rebase should change the\n\"# BASE\" comment, and then apply those patches which he/she is most\nfamiliar with.  When you hit a point where you need someone else's\nexpertise, you can do a \"(cd patches; git commit -a)\" to commit all of\nthe changes in the patch queue so far, and then let someone else take\nover.  \n\nThey would then do:\n\n# Pop all of the patches off the next developers work directory\nguilt pop -a\n# Update the patch queue\n(cd patches; guilt pull)\n# Now we need to make sure we have the latest kernel patches from mainline\ngit fetch\n# Now update the work directory to the version specified by the patch\n# series file\ngit merge $(head patches/series | sed -e 's/# BASE //')\n# Now resume trying to apply patches, one at a time...\n# next_patch\nguilt push -a\n# if there is a failed patch, force apply it and resolve patch rejects\nguilt push -f\n# refresh the patch\nguilt refresh --diffstat\n# .... and so on\n\nMy biggest suggestion, though, is to try to merge partial work earlier\nrather than later.  I'd try getting a partially functioning device\ndriver merged first, and then try to get the optimizations applied\nearlier.  If you don't want people using it in production, that's what\nthe EXPERIMENTAL tag is for...\n\n\n\t\t\t\t\t\t- Ted\n"},{"id":"118021","messageId":"m31voiuktb.fsf@localhost.localdomain","threadId":"20113","inReplyTo":"20090715122828.GA6570@mit.edu","subject":"Re: Dividing up a large merge.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-07-15T13:39:46Z","receivedAt":"2009-07-15T13:39:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> Yeah, that's another prime argument for maintaining your changes as a\n> patch queue.  I use a combination of quilt plus git.\n\nWhy not StGit, or Guilt, or TopGit?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"118027","messageId":"20090715144739.GA14846@cthulhu","threadId":"20113","inReplyTo":"20090715122828.GA6570@mit.edu","subject":"Re: Dividing up a large merge.","fromName":"Larry D'Anna","fromEmail":"larry@elder-gods.org","sentAt":"2009-07-15T14:47:39Z","receivedAt":"2009-07-15T14:47:39Z","isPatch":false,"sender":{"key":"larry@elder-gods.org","avatar":"https://avatars.githubusercontent.com/u/3013304?v=4"},"body":"* Theodore Tso (tytso@mit.edu) [090715 08:28]:\n> And, if you believe your release cycle is going to run for more than,\n> say, 2-3 months, I suggest that you keep things in a single linear\n> patch stream.  You can keep the patch series under git control, and\n> then rebase periodically; I'd suggest rebasing once a mainline release\n> happens (i.e., when 2.6.X is released), and then again after most of\n> the major changes have been merged in and the tree has settled down\n> (i.e., after 2.6.X-rc2 or 2.6.X-rc3).\n\nor use TopGit\n\nhttp://repo.or.cz/w/topgit.git\n\n        --larry\n"},{"id":"118036","messageId":"20090715160746.GI6570@mit.edu","threadId":"20113","inReplyTo":"m31voiuktb.fsf@localhost.localdomain","subject":"Re: Dividing up a large merge.","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2009-07-15T16:07:46Z","receivedAt":"2009-07-15T16:07:46Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Jul 15, 2009 at 06:39:46AM -0700, Jakub Narebski wrote:\n> Theodore Tso <tytso@mit.edu> writes:\n> \n> > Yeah, that's another prime argument for maintaining your changes as a\n> > patch queue.  I use a combination of quilt plus git.\n> \n> Why not StGit, or Guilt, or TopGit?\n\nSorry, typo; that should have read \"guilt\".  The example workflow I\nincluded used guilt commands.\n\n\t\t\t\t\t- Ted\n"},{"id":"118041","messageId":"alpine.LNX.2.00.0907151429490.2147@iabervon.org","threadId":"20113","inReplyTo":"20090715002926.GA26630@huya.quicinc.com","subject":"Re: Dividing up a large merge.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-07-15T18:57:59Z","receivedAt":"2009-07-15T18:57:59Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 14 Jul 2009, davidb@quicinc.com wrote:\n\n> On Tue, Jul 14, 2009 at 05:16:54PM -0700, Bryan Donlan wrote:\n> \n> > What do you mean by describing a merge? git is designed to have all\n> > the information needed for a merge inherent in the repository history.\n> \n> Yes, provided you can actually do the merge all at once.\n> \n> > Why are there so many conflicts to make this an issue?\n> \n> Because I have to work in the \"real world\".\n> \n> > If the commits are isolated to small changes, rebasing the developer\n> > topic branches instead of merging may help, by allowing you to take\n> > conflicts one commit at a time. For example, if your problems are\n> > primarily conflicts between developer branches and upstream:\n> \n> No real developer branches with conflicts (I make those be\n> fixed), but several upstreams.  We have many developers busily\n> doing work, and one or more other companies is also working on\n> the same code.  Meanwhile, the mainline kernel advances at it's\n> own astounding rate.\n> \n> Unfortunately, paying customers will always get priority of work,\n> even when that position is actually somewhat shortsighted and it\n> makes for a lot of merge effort later.\n> \n> The real issue is that there isn't any single individual who\n> understands all of the code that conflicts.  It has to be divided\n> up somehow, I'm just trying to figure out a better way of doing\n> it.\n\nIt sounds to me like you're maintaining an internal version that everybody \nmerges their stuff into, and you periodically merge that with the mainline \nkernel (generating a lot of conflicts which have to be resolved at the \nsame time). Instead of merging the branch that contains a lot of merges, \nit would probably be easier to merge into a clone of mainline each of the \nthings that was merged before. That is, instead of merging less than all \nof two trees, you'd merge commits which are not the newest commit on the \nbranch, choosing ones that individuals can resolve.\n\nThis also has the advantage where, if two of the changes affect an API \nthat's used in various different places, one person will get the \nresponsibility of resolving each of those conflicts, despite them being in \nthe middle of code they don't really understand, because they understand \nwhat happened with the API and therefore what has to be done in that \nlittle spot. Dividing the merge up by parts of the content would split \nthis work among people who aren't looking at the conflict in the \ndefinition of the API.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"118045","messageId":"20090715210113.GA18036@huya.quicinc.com","threadId":"20113","inReplyTo":"alpine.LNX.2.00.0907151429490.2147@iabervon.org","subject":"Re: Dividing up a large merge.","fromName":"","fromEmail":"davidb@quicinc.com","sentAt":"2009-07-15T21:01:13Z","receivedAt":"2009-07-15T21:01:13Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Wed, Jul 15, 2009 at 11:57:59AM -0700, Daniel Barkalow wrote:\n\n> It sounds to me like you're maintaining an internal version that everybody \n> merges their stuff into, and you periodically merge that with the mainline \n> kernel (generating a lot of conflicts which have to be resolved at the \n> same time). Instead of merging the branch that contains a lot of merges, \n> it would probably be easier to merge into a clone of mainline each of the \n> things that was merged before. That is, instead of merging less than all \n> of two trees, you'd merge commits which are not the newest commit on the \n> branch, choosing ones that individuals can resolve.\n\nThat's part of it, although I have a pretty good handle on that\npart.\n\nThe place where this comes up is that people in company X are\nworking on an internal version and company Y are working on a\nsimilar internal version.  We need to share back and forth\nbetween these more frequently than stuff gets into the mainline.\n\nWe do rebase at various points, but it takes quite a bit of work,\nand it's fairly different work than the conflicts I'm concerned\nwith here.\n\nThanks,\nDavid\n"}]}