Skip to main content

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

I had a look at how the commit-msg and pre-commit hooks are implemented. I don't think that it is a real problem to implement java hooks on top of that. That said, I do think that it will be a terrible pain to program the actual hooks then. In case of pre-commit, I have no access to the commit message, and in both cases the implementer will have to gather all interesting information on his own. Back when we discussed that feature @ EclipseCon, I liked the suggestion to verify the commit after it happened, because you essentially need to analyze the commit object only. You have all information in one place: message, committer, changed files, file sizes, other attributes, ...

How do you see this working? Is this OK? Does the feature make sense in this way? To be honest: before it is something that everybody is unhappy with, or that is a pain to use, or it turns out that our need is too special to be part of EGit, I'd rather implement a special solution just for us (we have our own EGit build anyway) than trying to force something upstream (it will not work anyway ;)). However I think that this feature could be beneficial to others too, so I'd really like to find a good solution together with you :)

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

Back to the top