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