[Bf-committers] How Merge master changes into remote branch

Julien RIVAUD (_FrnchFrgg_) frnchfrgg at free.fr
Wed Nov 20 23:02:01 CET 2013

Le 20/11/2013 21:49, Brecht Van Lommel a écrit :
> At the moment what we are advising is to rebase for local only
> branches, and merge for branches that are in the repository on
> git.blender.org, and so shared with others. When that branch is going
> to be merged into the master branch, it must be first locally rebased
> and then pushed.
To be clear, you mean that when a branch like soc-2013-sketch_mesh is 
ripe for integration, it should be rebased by the developer so that it 
can be integrated without merge ?

I agree that it can be good, if it means a rebase -i to essentially redo 
the branch from scratch with progressive modifications, that all build 
and are logical, like a patch series.
But for a big modification and/or a lot of commits it is going to be 
difficult, with a lot of rebase conflicts. Rebasing 400 commits can even 
then be more difficult than just taking the end result and split it in 
logical chunks, completely ignoring already existing history. But that 
too is really hard to do right: you don't want to commit the changes 
piecewise, you really want progressive changes that are logical on their 
own; that means that a commit in the series can (and should?) introduce 
code that will be removed/modified by a later commit of the same series.

Also, for branches that already live in git.blender.org (e.g. because 
they came from SVN), keep in mind that the commits are there and that 
duplicating them might be ineffective (sure, you can delete the branch 
which will gc those that become unreachable).
> In fact this policy is enforced by the git server now, if you try to
> do a force push anywhere it will reject it, and if you try to do a
> merge commit to the master branch it will reject that too.
Anyway, you can worry about that when the case arises.


More information about the Bf-committers mailing list