threads / discuss / 27967

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

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

## tl;dr

3 messages between Jul 31, 2011 and Jul 31, 2011.

replies: 2people: 2as markdown or json

Conrad Irwin· Jul 31, 2011, 00:54 UTC · lore
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
Jeff King· Jul 31, 2011, 05:53 UTC · re: Conrad Irwin · lore

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

On Sat, Jul 30, 2011 at 05:54:59PM -0700, Conrad Irwin wrote:
Show 15 quoted lines
> 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.

If you know M, then B is the merge-base of M^1 and M^2 (i.e., the parents of M). If you don't know M, but do know D, you can find it by walking backwards from "integration" until you find a merge commit with D as its second parent (e.g., by grepping "rev-list --parents").

Make sense?
-Peff
Conrad Irwin· Jul 31, 2011, 06:08 UTC · re: Jeff King · lore

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

On Sat, Jul 30, 2011 at 10:53 PM, Jeff King <peff@peff.net> wrote:
Show 8 quoted lines
> On Sat, Jul 30, 2011 at 05:54:59PM -0700, Conrad Irwin wrote:
>
> If you know M, then B is the merge-base of M^1 and M^2 (i.e., the
> parents of M). If you don't know M, but do know D, you can find it by
> walking backwards from "integration" until you find a merge commit with
> D as its second parent (e.g., by grepping "rev-list --parents").
>
> Make sense?
Yup. git rev-list was definitely the tool I was missing, thank you :).
Conrad
merge=$(git rev-list --parents integration |\
                 grep " $(git rev-parse topic)" | cut -d' ' -f 1)
split=$(git merge-base $merge^ $merge^2)
git rebase --onto master $split
git checkout master
git merge --no-ff topic

← back to recent threads