Moving a topic branch forward: rebase vs. resolve

Moving a topic branch forward: rebase vs. resolve

[Marc Singer]

In moving a topic branch forward from about 2.6.16 to 2.6.18-rc1, I'm
finding little solace in either rebase or resolve.


  REBASE

Rebase is an attractive method as it preserves the change history,
though in the end the only interesting bits are those that are merged
with master.  


  --1---2----3---4   master
     \
      --A--B--C      topic


In rebasing ABC at 4, it looks like git is applying each patch in
turn.  While this is strictly correct, it can make for a tedious merge
if both A and C modify the same piece of code *and* if revision 2
makes both A and C merge with conflicts.  The result was an exhausting
march through the change sets.


  RESOLVE

So, I tried resolve which I would expect to apply the other direction,
merging 234 onto C.  git-resolve finishes in a single pass leaving
conflict markers in a number of files.  However, some of these are
unexpected, conflicts in files that I've not and which I'd expect to
merge cleanly.  For example

    diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
    index 2975291..fea24ba 100644
    --- a/Documentation/DocBook/Makefile
    +++ b/Documentation/DocBook/Makefile
    @@ -2,15 +2,21 @@ ###
     # This makefile is used to generate the kernel documentation,
     # primarily based on in-line comments in various source files.
     # See Documentation/kernel-doc-nano-HOWTO.txt for instruction in how
    -# to ducument the SRC - and how to read it.
    +# to document the SRC - and how to read it.
     # To add a new book the only step required is to add the book to the
     # list of DOCBOOKS.

     DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
		kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
		procfs-guide.xml writing_usb_driver.xml \
    +<<<<<<< .merge_file_arWYZk
		kernel-api.xml journal-api.xml lsm.xml usb.xml \
		gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml
    +=======
    +           kernel-api.xml journal-api.xml lsm.xml usb.xml \
    +           gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
    +           genericirq.xml
    +>>>>>>> .merge_file_G8cSmh


We have a spelling fix and the addition of genericirq.xml.  What would
cause these sorts of conflicts?  Is there someting I can do to
eliminate them or resolve them properly?

Cheers.

Re: Moving a topic branch forward: rebase vs. resolve

[Linus Torvalds]

On Thu, 6 Jul 2006, Marc Singer wrote:
> 
> So, I tried resolve which I would expect to apply the other direction,
> merging 234 onto C.  git-resolve finishes in a single pass leaving
> conflict markers in a number of files.  However, some of these are
> unexpected, conflicts in files that I've not and which I'd expect to
> merge cleanly.  For example
> 
>     diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
>     index 2975291..fea24ba 100644
>     --- a/Documentation/DocBook/Makefile
>     +++ b/Documentation/DocBook/Makefile
>     @@ -2,15 +2,21 @@ ###
>      # This makefile is used to generate the kernel documentation,
>      # primarily based on in-line comments in various source files.
>      # See Documentation/kernel-doc-nano-HOWTO.txt for instruction in how
>     -# to ducument the SRC - and how to read it.
>     +# to document the SRC - and how to read it.
>      # To add a new book the only step required is to add the book to the
>      # list of DOCBOOKS.
> 
>      DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
> 		kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
> 		procfs-guide.xml writing_usb_driver.xml \
>     +<<<<<<< .merge_file_arWYZk
> 		kernel-api.xml journal-api.xml lsm.xml usb.xml \
> 		gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml
>     +=======
>     +           kernel-api.xml journal-api.xml lsm.xml usb.xml \
>     +           gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
>     +           genericirq.xml
>     +>>>>>>> .merge_file_G8cSmh
> 
> We have a spelling fix and the addition of genericirq.xml.  What would
> cause these sorts of conflicts?  Is there someting I can do to
> eliminate them or resolve them properly?

Well, the spelling fix was already merged properly. I can't tell why it 
thinks it conflicted on the addition of genericirq.xml, but it _looks_ 
like you may have done some whitespace changes. The merge result seems 
obvious (pick the second hunk, possibly editing the whitespace to match).

If you wonder why a merge clashes, and you want to see what both branches 
did, see the email thread a few days ago called "A note on merging 
conflicts" on how to efficiently and easily see what the changes were in 
both branches.

			Linus