On Tue, Nov 13, 2012 at 6:24 AM, Paul Davis <[email protected]>wrote:
> All that is to say, "no merges" or "allow all merges and public shaming > when someone screws up, and when someone screws up on master its permanent > cause we don't allow rewriting master". > I'm comfortable with this. Nobody should ever merge master into their feature or bug branch. If they do, we should catch it before it's merged to master (because we should be merging the public branch on asf, and not some local-I-did-a-git-pull-from-master-but-never-told-anyone branch). Do we allow rewrites on the feature branches? The danger in not merging from master into the branches is that there are conflicts when someone goes to merge the branch to master and then resolves it incorrectly. If we allow rewriting these feature branches, we can rebase and force push to them until it's a fast-forward to merge it to master (though, arguments for -no-ff include maintaining the 'grouping' of the commits as a branch, which is good for bisect, IIRC). Or, you know, whoever does the merge to master and resolves the conflicts should test it locally before pushing (is this reassuring enough?). Alternatively, what's the actual problem with having merges from master to the feature branch appearing in our history, aside from it being (to some eyes) "ugly"?
