How to rebase after upstream was merged?

How to rebase after upstream was merged?

[Johannes Sixt]

I have this history:

o--o--o--o--o   <- origin
    \        \
     x--x--x--M--x--x  <- master (HEAD)

At this point I would like to rebase to straighten the history, but it
won't let me:

    $ git rebase origin
    Current branch master is up to date.

However, if there were additional commits on origin, it would work as
expected, i.e. all the 'x', but not 'M',  would be moved on top of
origin. The reason is that rebase checks whether the merge base of
origin and HEAD is origin, and exits early if it is.

I would like to extend the check to also check for linear history. How
can I do this most efficiently? My first try is along these lines:

  test $(git rev-list origin..HEAD | wc -l) = \
       $(git rev-list --no-merges origin..HEAD | wc -l)

Is there a better approach?

-- Hannes

Re: How to rebase after upstream was merged?

[Johannes Schindelin]

Hi,

On Wed, 4 Jul 2007, Johannes Sixt wrote:

> I have this history:
> 
> o--o--o--o--o   <- origin
>     \        \
>      x--x--x--M--x--x  <- master (HEAD)
> 
> At this point I would like to rebase to straighten the history, but it
> won't let me:
> 
>     $ git rebase origin
>     Current branch master is up to date.

I'd do something like

$ git checkout -b tmp HEAD~3
$ git rebase origin
$ git checkout master
$ git rebase --onto tmp HEAD~2
$ git branch -d tmp

> I would like to extend the check to also check for linear history. How
> can I do this most efficiently? My first try is along these lines:
> 
>   test $(git rev-list origin..HEAD | wc -l) = \
>        $(git rev-list --no-merges origin..HEAD | wc -l)
> 
> Is there a better approach?

I usually to

	test -z "$(git rev-list --parents origin..HEAD | grep " .* ")"

Hth,
Dscho

Re: How to rebase after upstream was merged?

[Johannes Sixt]

Johannes Schindelin wrote:
> [...how to check for linear history...]
> I usually to
> 
>         test -z "$(git rev-list --parents origin..HEAD | grep " .* ")"

Ah, that's much better.

Thanks,
-- Hannes