[Development] Please warn of force pushes...

Oswald Buddenhagen oswald.buddenhagen at digia.com
Wed Apr 24 12:31:45 CEST 2013


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.



More information about the Development mailing list