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, 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>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