Re: [egit-dev] Commit Validation

[Duft Markus <Markus.Duft@xxxxxxxxxxxxxxxx>]

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