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 <[email protected]>: > > > > On Thu, Jul 3, 2014 at 7:36 AM, Raphael Valyi <[email protected]> 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 already give their time for >> free, even if that means putting more burden of the guys who contribute. >> In any case Github is lowering the contribution barrier a lot compared to >> Launchpad. >> >> So I would say if a PR is clean, let's jut allow to merge it with that >> merge button or git merge. >> >> Now, if a PR is not clean, >> then we still have 2 choices to avoid doing ugly merges: >> 1) ask the contributor to squash or rebase or clean in anyway >> > > 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 > > >> 2) the maintainer does the cleanup himself >> > > Would be better if contributor (PR owner) do it. > > >> >> A concrete example: last time when I submitted a patch to the Gollum >> project (derivated from github wiki), the maintainer asked me to squash >> several commits which I did and which was perfectly fine >> https://github.com/gollum/gollum/pull/787 >> He then probably used that merge button. Everybody fine, no maintenance >> hassle. >> > > Totally agree here. > >> >> > >> In any case we can avoid ugly merges without to have to put all the >> burden always on the maintainer as Leonardo said. >> >> >> Well, just my opinion. >> >> >> On Thu, Jul 3, 2014 at 9:16 AM, Leonardo Pistone < >> [email protected]> wrote: >> >>> IMHO, what maintainers did on Launchpad was to just to merge, thus >>> creating one new commit including all the changes in the feature >>> branch. In addition to that, we could to small modifications ourselves >>> before pushing to Launchpad. >>> >>> On the other hand, git makes it possible to do things that we would >>> not even dream to do practically with bazaar: an interactive rebase >>> allows to clean up history doing things like >>> >>> - rebasing the history, making it look like history is more linear >>> than it was at the start >>> - clean up history by squashing old commits together >>> - get rid of commits that break the automatic tests, allowing historic >>> operations like bisect and benchmarks on the history >>> - change past commit messages to make them better >>> >>> and so on. >>> >>> Or we can just use the "merge" button on github, that does the same >>> thing we did manually on Launchpad (clearly without the possibility to >>> make small changes ourselves). >>> >>> So IMO it's good to have some guidelines to contributors (i.e. try to >>> produce a clean history in their branch) but I would wait a bit before >>> forcing maintainers to have a complex workflow in all cases. >>> >>> In the meantime we can, for example, try to ask kindly to contributors >>> to improve their feature branches themselves, and use git-rebase-fu >>> only when necessary. >>> >>> On Thu, Jul 3, 2014 at 9:02 AM, Joël Grand-Guillaume >>> <[email protected]> wrote: >>> > I think, after reading carefully, that this is more important than it >>> seems. >>> > By increasing the number of project, it's important that such rule are >>> > given, even if not a constraint for now. But at least we should let >>> people >>> > now about. >>> > >>> > So I'm in favor of writing this in the docs and howto's. Committers >>> should >>> > now that IMO. >>> > >>> > Improving the quality is one of our goal, even if not applicable >>> eveytime by >>> > lack of time, it should be our goal. >>> > >>> > >>> > >>> > >>> > On Thu, Jul 3, 2014 at 12:05 AM, Nhomar Hernández <[email protected]> >>> wrote: >>> >> >>> >> 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 Manuel Baeza Romero" >>> >> <[email protected]> wrote: >>> >>> >>> >>> 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 GitHub >>> >>> was the Merge PR button. >>> >>> >>> >>> Regards. >>> >>> >>> >>> >>> >>> 2014-06-27 14:23 GMT+02:00 Tymoteusz Motylewski >>> >>> <[email protected]>: >>> >>>> >>> >>>> +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 history >>> >>>> >>> >>>> >>> http://docs.typo3.org/neos/TYPO3NeosDocumentation/Appendixes/ChangeLogs/102.html >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> 2014-06-27 13:51 GMT+02:00 Lionel Sausin <[email protected]>: >>> >>>> >>> >>>>> 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 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 thought I'd share this piece of insight with >>> all of >>> >>>>>> you. >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> Mailing list: https://launchpad.net/~openerp-community >>> >>>>> Post to : [email protected] >>> >>>>> Unsubscribe : https://launchpad.net/~openerp-community >>> >>>>> More help : https://help.launchpad.net/ListHelp >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> >>> >>>> Pozdrawiam serdecznie / Best regards >>> >>>> Tymoteusz Motylewski >>> >>>> Head of development >>> >>>> +48 502 472 202 >>> >>>> >>> >>>> [email protected] >>> >>>> >>> >>>> http://www.macopedia.pl/ >>> >>>> Ul. Roosevelta 5/8 >>> >>>> 60-829 Poznań >>> >>>> Tel. +48 61 622 96 95 >>> >>>> Fax +48 61 623 24 48/ >>> >>>> Macopedia Spółka z ograniczoną odpowiedzialnością, z siedzibą ul. >>> >>>> Roosevelta 5/8; 60-829 Poznań, wpisana do Krajowego Rejestru >>> Sądowego, >>> >>>> prowadzonego przez Sąd Rejonowy, VIII Wydział Gospodarczy, KRS >>> >>>> 0000416744, o opłaconym kapitale zakładowym w wysokości 5.000,00 >>> zł, o >>> >>>> numerze NIP: 781-187-78-41, numerze Regon 302076699 >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Mailing list: https://launchpad.net/~openerp-community >>> >>>> Post to : [email protected] >>> >>>> Unsubscribe : https://launchpad.net/~openerp-community >>> >>>> More help : https://help.launchpad.net/ListHelp >>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Mailing list: https://launchpad.net/~openerp-community >>> >>> Post to : [email protected] >>> >>> Unsubscribe : https://launchpad.net/~openerp-community >>> >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >> >>> >> _______________________________________________ >>> >> Mailing list: https://launchpad.net/~openerp-community >>> >> Post to : [email protected] >>> >> Unsubscribe : https://launchpad.net/~openerp-community >>> >> More help : https://help.launchpad.net/ListHelp >>> >> >>> > >>> > >>> > >>> > -- >>> > >>> > >>> > camptocamp >>> > INNOVATIVE SOLUTIONS >>> > BY OPEN SOURCE EXPERTS >>> > >>> > Joël Grand-Guillaume >>> > Division Manager >>> > Business Solutions >>> > >>> > +41 21 619 10 28 >>> > www.camptocamp.com >>> > >>> > >>> > >>> > _______________________________________________ >>> > Mailing list: https://launchpad.net/~openerp-community >>> > Post to : [email protected] >>> > Unsubscribe : https://launchpad.net/~openerp-community >>> > More help : https://help.launchpad.net/ListHelp >>> > >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openerp-community >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~openerp-community >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-community >> More help : https://help.launchpad.net/ListHelp >> >> > > > -- > > [image: Cristian Salamea on about.me] > > Cristian Salamea > about.me/ovnicraft > <http://about.me/ovnicraft> > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-community > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
