[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.
_FrnchFrgg_
More information about the Bf-committers
mailing list