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

[Joshua Leung]

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.


Regards,
Joshua


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