{"thread":{"id":"4788","subject":"Moving a topic branch forward: rebase vs. resolve","startedAt":"2006-07-06T21:10:08Z","lastAt":"2006-07-06T21:24:28Z","messageCount":2,"participants":["Marc Singer","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"23331","messageId":"20060706211008.GA6566@buici.com","threadId":"4788","inReplyTo":null,"subject":"Moving a topic branch forward: rebase vs. resolve","fromName":"Marc Singer","fromEmail":"woolie@cac.washington.edu","sentAt":"2006-07-06T21:10:08Z","receivedAt":"2006-07-06T21:10:08Z","isPatch":false,"sender":{"key":"woolie@cac.washington.edu","avatar":null},"body":"In moving a topic branch forward from about 2.6.16 to 2.6.18-rc1, I'm\nfinding little solace in either rebase or resolve.\n\n\n  REBASE\n\nRebase is an attractive method as it preserves the change history,\nthough in the end the only interesting bits are those that are merged\nwith master.  \n\n\n  --1---2----3---4   master\n     \\\n      --A--B--C      topic\n\n\nIn rebasing ABC at 4, it looks like git is applying each patch in\nturn.  While this is strictly correct, it can make for a tedious merge\nif both A and C modify the same piece of code *and* if revision 2\nmakes both A and C merge with conflicts.  The result was an exhausting\nmarch through the change sets.\n\n\n  RESOLVE\n\nSo, I tried resolve which I would expect to apply the other direction,\nmerging 234 onto C.  git-resolve finishes in a single pass leaving\nconflict markers in a number of files.  However, some of these are\nunexpected, conflicts in files that I've not and which I'd expect to\nmerge cleanly.  For example\n\n    diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile\n    index 2975291..fea24ba 100644\n    --- a/Documentation/DocBook/Makefile\n    +++ b/Documentation/DocBook/Makefile\n    @@ -2,15 +2,21 @@ ###\n     # This makefile is used to generate the kernel documentation,\n     # primarily based on in-line comments in various source files.\n     # See Documentation/kernel-doc-nano-HOWTO.txt for instruction in how\n    -# to ducument the SRC - and how to read it.\n    +# to document the SRC - and how to read it.\n     # To add a new book the only step required is to add the book to the\n     # list of DOCBOOKS.\n\n     DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \\\n\t\tkernel-hacking.xml kernel-locking.xml deviceiobook.xml \\\n\t\tprocfs-guide.xml writing_usb_driver.xml \\\n    +<<<<<<< .merge_file_arWYZk\n\t\tkernel-api.xml journal-api.xml lsm.xml usb.xml \\\n\t\tgadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml\n    +=======\n    +           kernel-api.xml journal-api.xml lsm.xml usb.xml \\\n    +           gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \\\n    +           genericirq.xml\n    +>>>>>>> .merge_file_G8cSmh\n\n\nWe have a spelling fix and the addition of genericirq.xml.  What would\ncause these sorts of conflicts?  Is there someting I can do to\neliminate them or resolve them properly?\n\nCheers.\n"},{"id":"23332","messageId":"Pine.LNX.4.64.0607061421100.3869@g5.osdl.org","threadId":"4788","inReplyTo":"20060706211008.GA6566@buici.com","subject":"Re: Moving a topic branch forward: rebase vs. resolve","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-06T21:24:28Z","receivedAt":"2006-07-06T21:24:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 6 Jul 2006, Marc Singer wrote:\n> \n> So, I tried resolve which I would expect to apply the other direction,\n> merging 234 onto C.  git-resolve finishes in a single pass leaving\n> conflict markers in a number of files.  However, some of these are\n> unexpected, conflicts in files that I've not and which I'd expect to\n> merge cleanly.  For example\n> \n>     diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile\n>     index 2975291..fea24ba 100644\n>     --- a/Documentation/DocBook/Makefile\n>     +++ b/Documentation/DocBook/Makefile\n>     @@ -2,15 +2,21 @@ ###\n>      # This makefile is used to generate the kernel documentation,\n>      # primarily based on in-line comments in various source files.\n>      # See Documentation/kernel-doc-nano-HOWTO.txt for instruction in how\n>     -# to ducument the SRC - and how to read it.\n>     +# to document the SRC - and how to read it.\n>      # To add a new book the only step required is to add the book to the\n>      # list of DOCBOOKS.\n> \n>      DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \\\n> \t\tkernel-hacking.xml kernel-locking.xml deviceiobook.xml \\\n> \t\tprocfs-guide.xml writing_usb_driver.xml \\\n>     +<<<<<<< .merge_file_arWYZk\n> \t\tkernel-api.xml journal-api.xml lsm.xml usb.xml \\\n> \t\tgadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml\n>     +=======\n>     +           kernel-api.xml journal-api.xml lsm.xml usb.xml \\\n>     +           gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \\\n>     +           genericirq.xml\n>     +>>>>>>> .merge_file_G8cSmh\n> \n> We have a spelling fix and the addition of genericirq.xml.  What would\n> cause these sorts of conflicts?  Is there someting I can do to\n> eliminate them or resolve them properly?\n\nWell, the spelling fix was already merged properly. I can't tell why it \nthinks it conflicted on the addition of genericirq.xml, but it _looks_ \nlike you may have done some whitespace changes. The merge result seems \nobvious (pick the second hunk, possibly editing the whitespace to match).\n\nIf you wonder why a merge clashes, and you want to see what both branches \ndid, see the email thread a few days ago called \"A note on merging \nconflicts\" on how to efficiently and easily see what the changes were in \nboth branches.\n\n\t\t\tLinus\n"}]}