[Bf-committers] How Merge master changes into remote branch
Brecht Van Lommel
brechtvanlommel at pandora.be
Thu Nov 21 02:19:08 CET 2013
>From the point of view of keeping it easy to do code reviews and to
keep Blender master stable, it's nice if what's coming in are easy to
understand incremental changes to the latest master. Sanitizing the
development history is work for developers but also a big help to the
I would rather do more regular code reviews and incrementally work
towards agreed on features in the master branch, keeping it always as
stable as possible, instead of having these disruptive big branch
merges. Ideally you aim for each commit to be a net improvement that
does not break anything. You can almost always refactor things
incrementally or have old and new code side by side.
We are wasting a lot of development time doing these big branches,
where people sort of sloppily start off, do hacks and break stuff with
the idea that they'll fix it all up later. And then it turns out
that's actually a lot more work than they expected and we end up
either with abandoned branches or an unstable master because of
pressure to merge those unstable branches, where it was near
impossible to properly the big changes.
So for me the whole idea of long lived branches is problematic, where
developers work for months in isolation without getting feedback and
code reviews and without seeing their work getting tested. If we had a
kind of multilevel review process like the linux kernel I can see that
working and I'd be happy to have merges into master, because what is
being merged has already been sanitized by code reviews at the lower
levels. But for Blender as it is organized now, I'm not so convinced.
This is one of the things I would really like to improve in the
development process, and I will encourage people to break up their
work into logical steps, send me and other core developers code
reviews early, and then try to have a quick turnaround for code
reviews. I think that will be more rewarding for people contributing
to Blender, and more manageable for people doing the code reviews and
(Ow, that end up being a lot more text than I expected, but I think
it's very important)
On Thu, Nov 21, 2013 at 1:09 AM, Joshua Leung <aligorith at gmail.com> wrote:
> Good points Julien/_FrnchFrgg_
> I'm personally of the opinion that usage of rebase in general is a Bad
> Thing (TM). For small/short-lived projects (or local feature branches for
> small features), it's probably ok to use rebase (though again, that depends
> heavily on the nature of how things developed).
> However, when you've got larger branches that have been going for a longer
> period of time, with somewhat complex history, IMO you're better off making
> an explicit merge (i.e. a "git merge --no-ff", perhaps followed by
> hand-editing of the merge commit's log message detailing the extent and
> implications of the branch which you've just merged in). By using rebase,
> you're throwing away a lot of contextual information about how the project
> developed - and end up wasting time "sanitising" the development history so
> that it will now make sense in light of this.
> Besides, adding rebase to your workflow just ends up complicating things.
> On Thu, Nov 21, 2013 at 11:02 AM, Julien RIVAUD (_FrnchFrgg_) <
> frnchfrgg at free.fr> wrote:
>> 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.
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers