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_ _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers