couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Allowing merge commits to master branch
Date Tue, 13 Nov 2012 22:14:34 GMT
On Tue, Nov 13, 2012 at 6:24 AM, Paul Davis <paul.joseph.davis@gmail.com>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"?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message