On Wed, Apr 24, 2013 at 09:23:54AM +0200, Olivier Goffart wrote: > Normaly, the way git was designed, is to use merges for this workflow. > In principle, rebasing should only be used for private branches. > And the winrt is not private. Not only it is public, but it is even part of > the main repsitory. > > You should only merge with dev when you really need a change from dev. You > may > also cherry pick, if you only want a single change. > > Rebasing is harmfull if anyone else if following this branch. > > So I would recommand doing merges instead of rebasing. > the thing is, if you want to merge to a mainline, each of your commits needs to comply with all of a mainline's policies, because your commits will become part of the mainline. this is not the case with winrt (and previous ports). therefore, the discussion is already over at this point.
but rebasing has other advantages, too. one is that conflicted merges are inherently evil. therefore, the fewer merges, the better. the second is that a clean workflow (discussion with concerned maintainers, submission for the right branch, integration, forward-merging) has a way too high latency. consequently, the teams take many shortcuts, which violates pretty much every aspect of the commit policy and produces a terrible history. rebasing is the only way to get that straightened out without holding up the ad-hoc development. the last (and imo deciding) point is: if the concerned team likes this workflow, it is good. it's ridiculous to make concessions for hypothetical drive-by contributors. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
