You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Robert Newson <ro...@gmail.com> on 2012/11/07 15:26:18 UTC
Allowing merge commits to master branch
All,
After 1.3.0, we agreed to work on feature branches and bugfix branches, and
then merge the results down after review.
We need a change to the git commit hooks to allow merge commits (they are
currently prohibited). Can I get some votes pls?
B.
Re: Allowing merge commits to master branch
Posted by Randall Leeds <ra...@gmail.com>.
+1
On Wed, Nov 7, 2012 at 6:26 AM, Robert Newson <ro...@gmail.com>wrote:
> All,
>
> After 1.3.0, we agreed to work on feature branches and bugfix branches, and
> then merge the results down after review.
>
> We need a change to the git commit hooks to allow merge commits (they are
> currently prohibited). Can I get some votes pls?
>
> B.
>
Re: Allowing merge commits to master branch
Posted by Paul Davis <pa...@gmail.com>.
As far as I know, I'm the only one that has a significant dislike of merge
commits. I'm willing to call lazy consensus in favor of allowing them. I'll
plan on reenabling them in a day or two to allow time for anyone speak up.
On Wed, Nov 7, 2012 at 3:40 PM, Robert Newson <rn...@apache.org> wrote:
> I think the wiki is a redo-from-start tbh. We shunt everything to an
> archive, and curate a collection of good pages into a new one. But also
> off-topic. :P
>
>
> On 7 November 2012 14:32, Dave Cottlehuber <dc...@jsonified.com> wrote:
>
> > On 7 November 2012 15:26, Robert Newson <ro...@gmail.com> wrote:
> > > All,
> > >
> > > After 1.3.0, we agreed to work on feature branches and bugfix branches,
> > and
> > > then merge the results down after review.
> > >
> > > We need a change to the git commit hooks to allow merge commits (they
> are
> > > currently prohibited). Can I get some votes pls?
> > >
> > > B.
> >
> > +1
> >
> > Do any of these need updating (or consolidating)?
> >
> > http://wiki.apache.org/couchdb/Release_Procedure
> > http://wiki.apache.org/couchdb/Source%20Code%20Repository%20Organization
> > http://wiki.apache.org/couchdb/CommitPolicy
> > http://wiki.apache.org/couchdb/ContributorWorkflow
> > http://wiki.apache.org/couchdb/SourceCode
> >
> > Less important but here for completeness:
> >
> > http://wiki.apache.org/couchdb/Git_At_Apache_Guide
> > http://wiki.apache.org/couchdb/SVNvsGIT
> > http://wiki.apache.org/couchdb/GitSuccessCriteria
> >
> > A+
> > Dave
> >
>
Re: Allowing merge commits to master branch
Posted by Octavian Damiean <ma...@gmail.com>.
I'm definitely +1 on this one.
On Wed, Nov 7, 2012 at 3:40 PM, Robert Newson <rn...@apache.org> wrote:
> I think the wiki is a redo-from-start tbh. We shunt everything to an
> archive, and curate a collection of good pages into a new one. But also
> off-topic. :P
>
>
> On 7 November 2012 14:32, Dave Cottlehuber <dc...@jsonified.com> wrote:
>
> > On 7 November 2012 15:26, Robert Newson <ro...@gmail.com> wrote:
> > > All,
> > >
> > > After 1.3.0, we agreed to work on feature branches and bugfix branches,
> > and
> > > then merge the results down after review.
> > >
> > > We need a change to the git commit hooks to allow merge commits (they
> are
> > > currently prohibited). Can I get some votes pls?
> > >
> > > B.
> >
> > +1
> >
> > Do any of these need updating (or consolidating)?
> >
> > http://wiki.apache.org/couchdb/Release_Procedure
> > http://wiki.apache.org/couchdb/Source%20Code%20Repository%20Organization
> > http://wiki.apache.org/couchdb/CommitPolicy
> > http://wiki.apache.org/couchdb/ContributorWorkflow
> > http://wiki.apache.org/couchdb/SourceCode
> >
> > Less important but here for completeness:
> >
> > http://wiki.apache.org/couchdb/Git_At_Apache_Guide
> > http://wiki.apache.org/couchdb/SVNvsGIT
> > http://wiki.apache.org/couchdb/GitSuccessCriteria
> >
> > A+
> > Dave
> >
>
Re: Allowing merge commits to master branch
Posted by Robert Newson <rn...@apache.org>.
I think the wiki is a redo-from-start tbh. We shunt everything to an
archive, and curate a collection of good pages into a new one. But also
off-topic. :P
On 7 November 2012 14:32, Dave Cottlehuber <dc...@jsonified.com> wrote:
> On 7 November 2012 15:26, Robert Newson <ro...@gmail.com> wrote:
> > All,
> >
> > After 1.3.0, we agreed to work on feature branches and bugfix branches,
> and
> > then merge the results down after review.
> >
> > We need a change to the git commit hooks to allow merge commits (they are
> > currently prohibited). Can I get some votes pls?
> >
> > B.
>
> +1
>
> Do any of these need updating (or consolidating)?
>
> http://wiki.apache.org/couchdb/Release_Procedure
> http://wiki.apache.org/couchdb/Source%20Code%20Repository%20Organization
> http://wiki.apache.org/couchdb/CommitPolicy
> http://wiki.apache.org/couchdb/ContributorWorkflow
> http://wiki.apache.org/couchdb/SourceCode
>
> Less important but here for completeness:
>
> http://wiki.apache.org/couchdb/Git_At_Apache_Guide
> http://wiki.apache.org/couchdb/SVNvsGIT
> http://wiki.apache.org/couchdb/GitSuccessCriteria
>
> A+
> Dave
>
Re: Allowing merge commits to master branch
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 7 November 2012 15:26, Robert Newson <ro...@gmail.com> wrote:
> All,
>
> After 1.3.0, we agreed to work on feature branches and bugfix branches, and
> then merge the results down after review.
>
> We need a change to the git commit hooks to allow merge commits (they are
> currently prohibited). Can I get some votes pls?
>
> B.
+1
Do any of these need updating (or consolidating)?
http://wiki.apache.org/couchdb/Release_Procedure
http://wiki.apache.org/couchdb/Source%20Code%20Repository%20Organization
http://wiki.apache.org/couchdb/CommitPolicy
http://wiki.apache.org/couchdb/ContributorWorkflow
http://wiki.apache.org/couchdb/SourceCode
Less important but here for completeness:
http://wiki.apache.org/couchdb/Git_At_Apache_Guide
http://wiki.apache.org/couchdb/SVNvsGIT
http://wiki.apache.org/couchdb/GitSuccessCriteria
A+
Dave
Re: Allowing merge commits to master branch
Posted by Randall Leeds <ra...@gmail.com>.
On Tue, Nov 13, 2012 at 6:24 AM, Paul Davis <pa...@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"?
Re: Allowing merge commits to master branch
Posted by Paul Davis <pa...@gmail.com>.
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".
On Tue, Nov 13, 2012 at 9:23 AM, Paul Davis <pa...@gmail.com>wrote:
> In theory that would be nice. In practice though its a whole lot harder.
> When you get into graphy things like this some assertions are harder than
> others.
>
> Preventing all merges is relatively easy, just check each commit pushed
> only has a single parent. To prevent the "merged master to master" you'd
> have to go through each merge commit and check where its parents led to.
> Though that gets a bit wonky cause of how branch names are temporary. More
> like what you'd want is to prevent merges that include one parent that
> points to a commit already on the other parent. Which is possible, but
> turns into a graph theory problem of a different nature. Because more like
> what you want is to prevent certain types of merges in general based on
> some patterns and that gets difficult enough for academic publication. Not
> the level of work I want to pursue for a git hook.
>
>
> On Thu, Nov 8, 2012 at 4:44 AM, Robert Newson <rn...@apache.org> wrote:
>
>> I wonder if we can loosen the hook script so it allows merge commits
>> between branches but not within them? The main reason merge commits are
>> disliked is when, usually by accident, a merge commit happens within a
>> single branch. That makes for confusing history merely because it was
>> pushed after someone else had updated the branch. If we all stick to the
>> rule of working on branches and only merging down when complete, this
>> shouldn't matter, but a script that prevents accidents would be very
>> handy.
>>
>>
>> On 8 November 2012 07:30, Paul Davis <pa...@gmail.com> wrote:
>>
>> > Merge commits have two parents. This is currently disabled by the git
>> hooks
>> > I wrote. Which affects things like GH PR's being automatically closed
>> when
>> > merged to master etc.
>> >
>> > The alternative method is to rebase commits to master which changes the
>> > sha1 which prevents Git from automatically tracking what branches
>> they're
>> > on.
>> >
>> >
>> > On Wed, Nov 7, 2012 at 9:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> >
>> > >
>> > > On Nov 7, 2012, at 15:26 , Robert Newson <ro...@gmail.com>
>> > wrote:
>> > >
>> > > > All,
>> > > >
>> > > > After 1.3.0, we agreed to work on feature branches and bugfix
>> branches,
>> > > and
>> > > > then merge the results down after review.
>> > > >
>> > > > We need a change to the git commit hooks to allow merge commits
>> (they
>> > are
>> > > > currently prohibited). Can I get some votes pls?
>> > >
>> > > Can you explain in two sentences each what the effective differences
>> are?
>> > > Just so we have it on record in this thread.
>> > >
>> > > Cheers
>> > > Jan
>> > > --
>> > >
>> > >
>> >
>>
>
>
Re: Allowing merge commits to master branch
Posted by Paul Davis <pa...@gmail.com>.
In theory that would be nice. In practice though its a whole lot harder.
When you get into graphy things like this some assertions are harder than
others.
Preventing all merges is relatively easy, just check each commit pushed
only has a single parent. To prevent the "merged master to master" you'd
have to go through each merge commit and check where its parents led to.
Though that gets a bit wonky cause of how branch names are temporary. More
like what you'd want is to prevent merges that include one parent that
points to a commit already on the other parent. Which is possible, but
turns into a graph theory problem of a different nature. Because more like
what you want is to prevent certain types of merges in general based on
some patterns and that gets difficult enough for academic publication. Not
the level of work I want to pursue for a git hook.
On Thu, Nov 8, 2012 at 4:44 AM, Robert Newson <rn...@apache.org> wrote:
> I wonder if we can loosen the hook script so it allows merge commits
> between branches but not within them? The main reason merge commits are
> disliked is when, usually by accident, a merge commit happens within a
> single branch. That makes for confusing history merely because it was
> pushed after someone else had updated the branch. If we all stick to the
> rule of working on branches and only merging down when complete, this
> shouldn't matter, but a script that prevents accidents would be very handy.
>
>
> On 8 November 2012 07:30, Paul Davis <pa...@gmail.com> wrote:
>
> > Merge commits have two parents. This is currently disabled by the git
> hooks
> > I wrote. Which affects things like GH PR's being automatically closed
> when
> > merged to master etc.
> >
> > The alternative method is to rebase commits to master which changes the
> > sha1 which prevents Git from automatically tracking what branches they're
> > on.
> >
> >
> > On Wed, Nov 7, 2012 at 9:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >
> > >
> > > On Nov 7, 2012, at 15:26 , Robert Newson <ro...@gmail.com>
> > wrote:
> > >
> > > > All,
> > > >
> > > > After 1.3.0, we agreed to work on feature branches and bugfix
> branches,
> > > and
> > > > then merge the results down after review.
> > > >
> > > > We need a change to the git commit hooks to allow merge commits (they
> > are
> > > > currently prohibited). Can I get some votes pls?
> > >
> > > Can you explain in two sentences each what the effective differences
> are?
> > > Just so we have it on record in this thread.
> > >
> > > Cheers
> > > Jan
> > > --
> > >
> > >
> >
>
Re: Allowing merge commits to master branch
Posted by Robert Newson <rn...@apache.org>.
I wonder if we can loosen the hook script so it allows merge commits
between branches but not within them? The main reason merge commits are
disliked is when, usually by accident, a merge commit happens within a
single branch. That makes for confusing history merely because it was
pushed after someone else had updated the branch. If we all stick to the
rule of working on branches and only merging down when complete, this
shouldn't matter, but a script that prevents accidents would be very handy.
On 8 November 2012 07:30, Paul Davis <pa...@gmail.com> wrote:
> Merge commits have two parents. This is currently disabled by the git hooks
> I wrote. Which affects things like GH PR's being automatically closed when
> merged to master etc.
>
> The alternative method is to rebase commits to master which changes the
> sha1 which prevents Git from automatically tracking what branches they're
> on.
>
>
> On Wed, Nov 7, 2012 at 9:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> >
> > On Nov 7, 2012, at 15:26 , Robert Newson <ro...@gmail.com>
> wrote:
> >
> > > All,
> > >
> > > After 1.3.0, we agreed to work on feature branches and bugfix branches,
> > and
> > > then merge the results down after review.
> > >
> > > We need a change to the git commit hooks to allow merge commits (they
> are
> > > currently prohibited). Can I get some votes pls?
> >
> > Can you explain in two sentences each what the effective differences are?
> > Just so we have it on record in this thread.
> >
> > Cheers
> > Jan
> > --
> >
> >
>
Re: Allowing merge commits to master branch
Posted by Paul Davis <pa...@gmail.com>.
Merge commits have two parents. This is currently disabled by the git hooks
I wrote. Which affects things like GH PR's being automatically closed when
merged to master etc.
The alternative method is to rebase commits to master which changes the
sha1 which prevents Git from automatically tracking what branches they're
on.
On Wed, Nov 7, 2012 at 9:43 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Nov 7, 2012, at 15:26 , Robert Newson <ro...@gmail.com> wrote:
>
> > All,
> >
> > After 1.3.0, we agreed to work on feature branches and bugfix branches,
> and
> > then merge the results down after review.
> >
> > We need a change to the git commit hooks to allow merge commits (they are
> > currently prohibited). Can I get some votes pls?
>
> Can you explain in two sentences each what the effective differences are?
> Just so we have it on record in this thread.
>
> Cheers
> Jan
> --
>
>
Re: Allowing merge commits to master branch
Posted by Jan Lehnardt <ja...@apache.org>.
On Nov 7, 2012, at 15:26 , Robert Newson <ro...@gmail.com> wrote:
> All,
>
> After 1.3.0, we agreed to work on feature branches and bugfix branches, and
> then merge the results down after review.
>
> We need a change to the git commit hooks to allow merge commits (they are
> currently prohibited). Can I get some votes pls?
Can you explain in two sentences each what the effective differences are?
Just so we have it on record in this thread.
Cheers
Jan
--