Automatically identifying the "split" point of a merged branch.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Gitters,

I wonder if I might pick your brains on the best way to handle a
situation I found myself in recently:

We have an integration branch, and a master branch, and a topic branch
that was based on the integration branch. Graphically:

A-o-o-o-o-o-o-o-o-o-E-(master)
 \
  o-o-B-o-o-o-o-M-o-o(integration)
       \       /
        C-o-o-D (topic)

I wanted to introduce this branch onto master to end up with:

A-o-o-o-o-o-o-o-o-o-E-----------N (master)
 \                   \         /
  \                   C'-o-o-D' (topic-rebased)
   \
    o-o-B-o-o-o-o-M-o-o(integration)
         \       /
          C-o-o-D (topic)

(ASCII art reproduced at http://dpaste.org/GUmM/ lest it be munged)

While it's easy to create comit N once I have commit D' (with git
merge --no-ff), I found that it's not at all easy to work out where
commit B is in order to do do a rebase --onto master B.

My usual approach would be to try and use git merge-base, but because
the topic branch is already merged into the integration branch, that
doesn't give useful output.

Is there a good way around this?

Conrad
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]