Skip to main content

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

On Thu, Mar 12, 2015 at 7:27 AM, Duft Markus <Markus.Duft@xxxxxxxxxxxxxxxx> wrote:
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 

I appreciate that you are looking into more powerful validation.
I think it makes sense to provide more powerful validations which are better integrated into 
the Eclipse workbench than what can be done in scripted hooks.

I think we should go one step farther than what you propose.
I wonder if validators should create problem markers [1] and the git commands like
the commit command should check if problems of certain types/severity exist in order
to decide if it's ok to create a commit or if just to show there are problems.

Which problem types/severities should be reported and/or block git commands should be configurable.

This way we would gain an integration with other validators like build, compiler warnings etc
without imposing an EGit specific API for integrating them.

So you could e.g. configure that a warning should be shown in the commit dialog/staging view
if there are compiler warnings of a certain kind. Or commit could be blocked if the code doesn't
compile. We could add new validators for git specific validations like a commit message validator
checking if formatting of the commit message is ok, contains a link to a bug etc.

Validations could be also integrated with other git commands, e.g. if you want to prevent
that large blobs are entering the git repository the best place to block that would be the AddCommand
since as soon as you staged the big file it's already in the object store of your git repository.

We could use the problem view to display the problems and even implement quick fixes for
git specific new problem types.


-Matthias 

Back to the top