Il giorno lun 19 nov 2018 alle ore 22:41 Enrico Olivelli <eolive...@gmail.com> ha scritto: > > We can run the script in Travis, so that we will refuse any commit > message not compliant with the "specs" > In Travis you can run a shell script with uses directly the 'git' command
What about this github plugin ? https://github.com/probot/semantic-pull-requests Enrico > > > Enrico > > Il giorno lun 19 nov 2018 alle ore 22:35 Francis Chuang > <francischu...@apache.org> ha scritto: > > > > I am not sure about server-side hooks on ASF's git. It would require > > execution privileges on ASF's git instance (for Github, this is not > > allowed). > > > > For Windows, I use WSL (Windows Subsystem for Linux). This is a copy of > > Ubuntu or some other supported Linux distro that runs within Windows and > > allows the execution of Linux executables on Windows. WSL translates > > calls to Windows native calls where needed. The downside is that WSL > > only works on Windows 10 1607 (released august/july 2016) and later, so > > people using Windows 8 and Windows 7 will not be able to use it. > > > > Francis > > > > On 20/11/2018 8:21 am, Julian Hyde wrote: > > > Are we allowed to create hooks in ASF’s git? > > > > > > If we add a shell script, are we excluding Windows folks? (Or can we > > > require them to install Cygwin?) > > > > > >> On Nov 19, 2018, at 1:15 PM, Michael Mior <mm...@apache.org> wrote: > > >> > > >> Sure, a shell script would work just fine as well. Really we just need to > > >> create a symlink in the .git/hooks directory that points to a script > > >> which > > >> performs whatever checks we want. > > >> -- > > >> Michael Mior > > >> mm...@apache.org > > >> > > >> > > >> Le lun. 19 nov. 2018 à 16:11, Francis Chuang <francischu...@apache.org> a > > >> écrit : > > >> > > >>> Will a shell script (instead of bringing in maven) running a regex check > > >>> (our use-case seems simple enough for a regex check so far) be > > >>> sufficient? This would avoid the need to set up a Java + maven > > >>> environment to commit code (in my case, I prefer to run maven and Java > > >>> in docker containers). > > >>> > > >>> Francis > > >>> > > >>> On 20/11/2018 8:00 am, Michael Mior wrote: > > >>>> Sorry, that link should have been > > >>>> https://github.com/phillipuniverse/githook-maven-plugin. Anyway, I > > >>>> don't > > >>>> have experience with any particular plugin, but git hooks seem to be > > >>>> the > > >>>> obvious way to go and that's the first one I found. > > >>>> > > >>>> -- > > >>>> Michael Mior > > >>>> mm...@apache.org > > >>>> > > >>>> > > >>>> Le lun. 19 nov. 2018 à 15:36, Enrico Olivelli <eolive...@gmail.com> a > > >>>> écrit : > > >>>> > > >>>>> Il lun 19 nov 2018, 21:29 Michael Mior <mm...@apache.org> ha scritto: > > >>>>> > > >>>>>> How about making use of > > >>>>> https://github.com/olukyrich/githook-maven-plugin? > > >>>>>> A post-commit hooks in git seems to be an easy way to achieve this. > > >>>>>> Unfortunately, it would require that each fresh clone of the > > >>>>>> repository > > >>>>> has > > >>>>>> a one-time command run to install the hook. > > >>>>>> > > >>>>> Michael, > > >>>>> It seems this plugin is notnot available on maven central > > >>>>> https://github.com/olukyrich/githook-maven-plugin > > >>>>> > > >>>>> Do you have experience with it? > > >>>>> Enrico > > >>>>> > > >>>>>> -- > > >>>>>> Michael Mior > > >>>>>> mm...@apache.org > > >>>>>> > > >>>>>> > > >>>>>> Le lun. 19 nov. 2018 à 14:49, Julian Hyde <jh...@apache.org> a écrit > > >>>>>> : > > >>>>>> > > >>>>>>>> On Nov 19, 2018, at 11:19 AM, Vladimir Sitnikov < > > >>>>>>> sitnikov.vladi...@gmail.com> wrote: > > >>>>>>>> Well, a rule of "first line should be separated by a blank line" > > >>>>> seems > > >>>>>> to > > >>>>>>>> be automatable. > > >>>>>>>> The rule of "CALCITE-XXX should be in [...]" seems to be > > >>>>>>>> automatable. > > >>>>>>>> And so on. > > >>>>>>> Yes, we should do that. > > >>>>>>> > > >>>>>>> However there are things that automation could never achieve, so > > >>>>>>> let’s > > >>>>>>> continue to talk about those, also. > > >>>>>>> > > >>>>>>>> setDynamicParam did not look good enough to me > > >>>>>>>> > > >>> https://git-wip-us.apache.org/repos/asf?p=calcite.git;a=blobdiff;f=core/src/main/java/org/apache/calcite/runtime/ResultSetEnumerable.java;h=52c11f9aaf752cea367ae921c04a20e5e6da5488;hp=771772f1ea39d74eee6e9f889ae8d6500f129c7f;hb=53e15af6c5e8e782b2edcd7f5bf4f5f32225d110;hpb=02ca9bc995cac5b4b97855a4d06df46e632d7c22 > > >>>>>>>> I'm inclined to incline Avatica to expose > > >>>>>>>> TypedValue.setToPreparedStatement(PreparedStatement ps, int index) > > >>>>> kind > > >>>>>>> of > > >>>>>>>> API, so ResultSetEnumerable.setDynamicParam could be removed > > >>>>>> altogether. > > >>>>>>> I agree. The commit didn’t seem quite perfect to me either. However, > > >>> it > > >>>>>>> seemed to be progress. Log an Avatica JIRA if you have ideas for how > > >>> to > > >>>>>>> improve it further. Since it will be in Avatica it will take a while > > >>> to > > >>>>>>> bubble through the release cycle. > > >>>>>>> > > >>>>>>> Julian > > >>>>>>> > > >>>>>>> > > >>>>> -- > > >>>>> > > >>>>> > > >>>>> -- Enrico Olivelli > > >>>>> > > >>> > >
