Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] Commit Validation

Hey all,

It's gotten quite silent about this. Could somebody give any feedback on the change? I'm OK with "we won't accept it this way" also ;) (maybe as long as there is a viable alternative to do something similar in quality for the end-user).

Just as a demo on how I imagine validators based on the change (real world examples): https://drive.google.com/folderview?id=0B05h8C3gLt38MVlvOFFaUlh4Yk0&usp=sharing

Cheers,
Markus

> -----Ursprüngliche Nachricht-----
> Von: Duft Markus
> Gesendet: Dienstag, 10. März 2015 08:47
> An: Duft Markus; Halstrick, Christian; Andrey Loskutov
> Cc: EGit developer discussion (egit-dev@xxxxxxxxxxx)
> Betreff: AW: [egit-dev] Commit Validation
>
> Just to show you how I think this could look like: https://git.eclipse.org/r/43498
>
> Having some code to dicuss maybe helps :)
>
> Cheers,
> Markus
>
> > -----Ursprüngliche Nachricht-----
> > Von: egit-dev-bounces@xxxxxxxxxxx [mailto:egit-dev-bounces@xxxxxxxxxxx] Im Auftrag von Duft Markus
> > Gesendet: Dienstag, 10. März 2015 07:34
> > An: Halstrick, Christian; Andrey Loskutov
> > Cc: EGit developer discussion (egit-dev@xxxxxxxxxxx)
> > Betreff: Re: [egit-dev] Commit Validation
> >
> > Hey,
> >
> > I had a look at how hooks work right now, and at how the result could possibly bubble up into EGit. I found out that:
> >
> > 1) There is a subtle difference to what I want: GIT hooks exist once whereas I would like to register multiple validators.
> > OTOH I don't really care the exact stage of the commit (commit-msg, pre-commit, ...), but rather require all information at
> > the programmers fingertips for easy to write validation. ("Should all hooks/validators run, or only one?"). Also (thought
> > about it) I don't actually need the ability to reject the commit - it's OK to inform the user that he/she must change &
> > amend.
> > 2) Hooks are actually not integrated nicely into EGit (It's OK from a JGit POV), as Andrey already pointed out. Improving
> this
> > would require special handling of special Exceptions, extracting them out of Runnables where they are caught currently
> and
> > converted in an "internal error" - not so nice. This kind of "let's route an exception out of a runnable" code is most of the
> > time not very ... intuitive, so maybe there is a better solution to that?
> > 3) To be able to piggyback java validation results on the AbortedByHookException there'd be some work to find a
> common
> > API for both use-cases.
> >
> > All in all, I'd rather leave the "GIT standard hooks" as they are, as they are well defined by upstream GIT already. I think a
> > separate validation mechanism would make more sense. If you think different, then please let me know how you think
> this
> > would fit together, as I just cannot see it ;)
> >
> > Cheers,
> > Markus
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Halstrick, Christian [mailto:christian.halstrick@xxxxxxx]
> > > Gesendet: Montag, 9. März 2015 11:38
> > > An: Andrey Loskutov; Duft Markus
> > > Cc: EGit developer discussion (egit-dev@xxxxxxxxxxx)
> > > Betreff: RE: [egit-dev] Commit Validation
> > >
> > > I also think that we should try to use hooks for this purpose. Validating commits is a very common use case for hooks
> and
> > > many people write scripted hooks to achieve that. As Andrey also mentioned let's not invent another way to achieve
> > that.
> > > On the other hand I understand why you want to avoid scripting. But since we already have a way how we call external
> > > scripts it should be not so hard to call Java instead.  See [1], [2]. Having a subclass of GitHook which calls Java instead of
> > > external processes in doRun() should be easy, or? Just as a proof of concept one could start trying this. But of course
> > more
> > > work is coming then (how to register, to to deploy hooks to installed IDEs (you have your own build of E/JGit, right?).
> But I
> > > guess it's less work than creating a new thing like validators separate from hooks.
> > >
> > > [1] https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit/src/org/eclipse/jgit/api/CommitCommand.java#L178
> > > [2] https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit/src/org/eclipse/jgit/hooks/GitHook.java#L147-L157
> > >
> >
> > Salomon Automation GmbH | Friesachstrasse 15 | 8114 Friesach bei Graz | Austria
> > Registered Office: Friesach bei Graz | Commercial Register: 49324 K | VAT no. ATU28654300
> > Commercial Court: Landesgericht für Zivilrechtssachen Graz
> > _______________________________________________
> > egit-dev mailing list
> > egit-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/egit-dev
Salomon Automation GmbH | Friesachstrasse 15 | 8114 Friesach bei Graz | Austria
Registered Office: Friesach bei Graz | Commercial Register: 49324 K | VAT no. ATU28654300
Commercial Court: Landesgericht für Zivilrechtssachen Graz

Back to the top