[Bf-committers] Git rebase/merge question

[Antonio Ospite]

On Thu, 1 May 2014 07:00:03 -0300
Dalai Felinto <dfelinto at gmail.com> wrote:

> Hi all,
> 
> I have a public branch (bake-cycles in git.blender.org) that started from a
> local branch, where I was using rebase from master all the time, but moved
> to upstream, where I've been doing merges from master often.
>
> Now that the time to merge back to master is coming close, I want to squash
> most of my old commits in logical blocks. The problem is, although when I
> was working locally my commits were all nicely stacked together (due to
> rebase), they are now scattered all over the git log (due to merge).
> 
> Is there an automatic way to convert a "merge branch" into a "rebase
> branch"? Once I had a "rebase branch" it would be much easier for me to do
> some rebase -i for squashing and re-order commits for the final merge.
> 
> Otherwise I will have to resort to splitting the commits based on the
> files, which is not ideal in my case.
>

Rebasing a public branch is discouraged in git, as people who pulled
already from that branch may see duplicated commits (the rebase
operation creates "new" commits with the same contents, in fact the
hashes change).

You can always create a new local branch from the public branch
(e.g. bake-cycles-final) and rebase that one and publish it when you
are ready.

This is the generic way, I don't know the details about the blender
workflow, sorry.

Ciao,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?