2013/11/20 Joshua Leung <[email protected]>: > 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.
You mean, when merging to master? > > Besides, adding rebase to your workflow just ends up complicating things. > > I agree that rebase is a feature that takes a lot of pain to learn how to use judiciously, but IMO it helps a lot with a clean history. -- Best Regards, Wander Lairson Costa _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
