Hello,
+1
for what Leornardo said.
There are huge Github projects such as Rails that use these merge buttons
just fine and are some of the most successful projects around...
We should free maintainers from work, who already give their time for free,
even if that means putting more burden of the
On Thu, Jul 3, 2014 at 7:36 AM, Raphael Valyi rva...@gmail.com wrote:
Hello,
+1
for what Leornardo said.
There are huge Github projects such as Rails that use these merge buttons
just fine and are some of the most successful projects around...
We should free maintainers from work, who
On rebase vs pull requests, this is a good read:
http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/
Notice the difference between rebase as local cleanup and rebase as team
policy.
2014-07-03 16:13 GMT+02:00 Ovnicraft ovnicr...@gmail.com:
On Thu, Jul 3, 2014 at 7:36 AM,
2014-07-03 9:43 GMT-04:30 Ovnicraft ovnicr...@gmail.com:
Yes please, rebase is the best AFAIK to keep clean PRs, here we are
working too with edX and that project has a good wiki about rebase
https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
Really thanks Cristian, it
On Thu, Jul 3, 2014 at 9:35 AM, Nhomar Hernández nho...@gmail.com wrote:
2014-07-03 9:43 GMT-04:30 Ovnicraft ovnicr...@gmail.com:
Yes please, rebase is the best AFAIK to keep clean PRs, here we are
working too with edX and that project has a good wiki about rebase
On Thu, Jul 3, 2014 at 11:35 AM, Nhomar Hernández nho...@gmail.com wrote:
2014-07-03 9:43 GMT-04:30 Ovnicraft ovnicr...@gmail.com:
Yes please, rebase is the best AFAIK to keep clean PRs, here we are
working too with edX and that project has a good wiki about rebase
[offtopic]:
don't forget this excellent reference learning material for git:
http://git-man-page-generator.lokaltog.net/
Out of curiosity, in case you're wondering how these generators work,
they're based on Markov chains
(https://en.wikipedia.org/wiki/Markov_chain):
- based on the original
We have to set new contributing HowTos for working with GitHub, and this
article points out some troubles with Merge PR button, but the way it says
to merge PR can be very laborious for maintainers. Can we assume this
amount of extra work? One of the highlights we talk about when the switch
to
Pedro.
It is a good to have but I think we can just pull locally test and then
push.
If you do this process recommended it ia good too! But IMHO Not the rule
for now.
Be careful! The pr button is dangerous without a correct CIS configured.
Written from my android
On Jul 2, 2014 3:16 PM, Pedro
Hello,
I found this blog post both interesting and useful :
http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful
Leonardo Pistone had shown me https://github.com/github/hub before and
it's a nice tool. And since odoo and the community addons are moving to
a new platform, I
Very interesting reading. I totally support this point of view even if
I'm only a contributor - clean history is hours not lost searching for
stuff. Bisect, annotate, etc all become easier.
Le 27/06/2014 12:10, Alexandre Fayolle a écrit :
Hello,
I found this blog post both interesting and
+1 for the clean git history. Merge commits are painful.
With clean commit messages and linear history things like changelog can be
easily generated automatically. And by changelog I mean sth which really
gives the reader some knowledge.
See other OSS project TYPO3 Neos for example of such a
12 matches
Mail list logo
