Is there any way to default the "merge button on pull requests" to default to the rebase strategy? On 25-04-13 15:59, Edson Tirelli wrote: All, We noticed lately that an increasing number of git merges is happening in the Drools/jBPM codebase. Git merges can be easily identified in the "network" graph in github repo, or by using any other Git client tool, as parallel lines in the branch history. E.g.: https://github.com/droolsjbpm/droolsjbpm-knowledge/network Please note that each and every merge, while not a big problem by itself, increases the risk of overriding code changes (i.e., losing code) as well as increases future maintenance cost. If you want know more about it, feel free to ask, or just trust me on this... :) Git offers an alternative to merges in the form of "rebase". Rebase enables developers to commit code on top of the most recent change in the branch, instead of in parallel to it. It guarantees no code will be lost when doing that, and makes it easier to maintain code in the future. If you don't know how to rebase code, please read one of the many git books/documentation available on line, like: http://git-scm.com/book Also feel free to ask and I will be happy to help. There is just one case where rebase can not be used: * You should NEVER rebase a commit that was published to a public repository before. Also, the github pull request "merge" button uses merge instead of rebase. While it is very quick and easy for a developer to click on that button, please note that it introduces merges, and at the same time commits code that was not tested by the person doing the merge. It is acceptable for small code fixes, but for anything larger than a few lines of code changes, you should pull the changes into your machine rebasing them, run the tests to make sure they are still clean and only after that push the PR changes to the public repo. Please be aware of that and try to minimize merges by using rebase whenever possible. Thanks, -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

On 25-04-13 16:43, Edson Tirelli wrote: Geoffrey, No idea, but I think the main issue with the PR merge button is that by clicking on it, we are "blindly" accepting the code changes without testing on our machine first. So for a couple lines of code changes, like a fix on typos or docs, it is fine, Even for typo's and a few lines of codes, we 'll want to have a rebase right? But not using the PR merge button for a typo PR is way too much overhead. but for anything larger we should be pulling the PR into our local code base, rebasing it, running the tests and only after that pushing to the public repo.... At least, this is how I see it... Edson On Thu, Apr 25, 2013 at 10:36 AM, Geoffrey De Smet < ge0ffrey.spam(a)gmail.com&gt; wrote: > Is there any way to default the "merge button on pull requests" to > default to the rebase strategy? > > > On 25-04-13 15:59, Edson Tirelli wrote: > > > All, > > We noticed lately that an increasing number of git merges is > happening in the Drools/jBPM codebase. Git merges can be easily identified > in the "network" graph in github repo, or by using any other Git client > tool, as parallel lines in the branch history. E.g.: > > https://github.com/droolsjbpm/droolsjbpm-knowledge/network > > Please note that each and every merge, while not a big problem by > itself, increases the risk of overriding code changes (i.e., losing code) > as well as increases future maintenance cost. If you want know more about > it, feel free to ask, or just trust me on this... :) > > Git offers an alternative to merges in the form of "rebase". Rebase > enables developers to commit code on top of the most recent change in the > branch, instead of in parallel to it. It guarantees no code will be lost > when doing that, and makes it easier to maintain code in the future. If you > don't know how to rebase code, please read one of the many git > books/documentation available on line, like: > > http://git-scm.com/book > > Also feel free to ask and I will be happy to help. > > There is just one case where rebase can not be used: > > * You should NEVER rebase a commit that was published to a public > repository before. > > Also, the github pull request "merge" button uses merge instead of > rebase. While it is very quick and easy for a developer to click on that > button, please note that it introduces merges, and at the same time commits > code that was not tested by the person doing the merge. It is acceptable > for small code fixes, but for anything larger than a few lines of code > changes, you should pull the changes into your machine rebasing them, run > the tests to make sure they are still clean and only after that push the PR > changes to the public repo. > > Please be aware of that and try to minimize merges by using rebase > whenever possible. > > Thanks, > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss by Red Hat @ www.jboss.com > > > _______________________________________________ > rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

All, We noticed lately that an increasing number of git merges is happening in the Drools/jBPM codebase. Git merges can be easily identified in the "network" graph in github repo, or by using any other Git client tool, as parallel lines in the branch history. E.g.: https://github.com/droolsjbpm/droolsjbpm-knowledge/network Please note that each and every merge, while not a big problem by itself, increases the risk of overriding code changes (i.e., losing code) as well as increases future maintenance cost. If you want know more about it, feel free to ask, or just trust me on this... :) Git offers an alternative to merges in the form of "rebase". Rebase enables developers to commit code on top of the most recent change in the branch, instead of in parallel to it. It guarantees no code will be lost when doing that, and makes it easier to maintain code in the future. If you don't know how to rebase code, please read one of the many git books/documentation available on line, like: http://git-scm.com/book Also feel free to ask and I will be happy to help. There is just one case where rebase can not be used: * You should NEVER rebase a commit that was published to a public repository before. Also, the github pull request "merge" button uses merge instead of rebase. While it is very quick and easy for a developer to click on that button, please note that it introduces merges, and at the same time commits code that was not tested by the person doing the merge. It is acceptable for small code fixes, but for anything larger than a few lines of code changes, you should pull the changes into your machine rebasing them, run the tests to make sure they are still clean and only after that push the PR changes to the public repo. Please be aware of that and try to minimize merges by using rebase whenever possible. Thanks, -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev