Re: [egit-dev] Commit Validation

["Andrey Loskutov" <loskutov@xxxxxx>]

Few notes:

 

1) IMHO Egit should not create markers since it does not listen to the resource modificatons (is the problem fixed?) and also does not contribute builders to the projects.

The problem with the markers is that user expects that they disappear after the problem is resolved or after "clean project", but if there is no egit listener/builder on the project, they will remain. We could add such a builder, but this is going out of the original proposal's scope (the builder will need to run pre-commit validators over each changed file, so that user could see the warnings even *before* commiting the stuff). This is interesting idea and deserves an extra discussion. Just imagine we would see all the "trailing white space" errors before they will appear in the gerrit.

 

What we can initially do is just to run validators each time an entry appears in the staging view and also decorate entries in the staging view with extra information (all icons/font/text labels are possible), and even eventually disabling the commit button while showing "commit validation rule error on file xyz" error description in the staging view.
 

2) Matthias, me and Christian - we all understand this validation as "pre-commit" thing, which *prevents* commit to happen if something is not OK. Markus proposal works *after the fact*, and this is an important difference. From the user perspective it does really not make sense to fiddle with "bad" commit, it is not user friendly. I guess no one of my coworkers ever ameded a commit or tried to modify the history in any way. So if implementing validators, they must be *pre*-commit/pre-push etc.

 

Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov

 

 

Gesendet: Donnerstag, 12. März 2015 um 17:48 Uhr
Von: "Matthias Sohn" <matthias.sohn@xxxxxxxxx>
An: "Duft Markus" <Markus.Duft@xxxxxxxxxxxxxxxx>
Cc: "Halstrick, Christian" <christian.halstrick@xxxxxxx>, "Andrey Loskutov" <loskutov@xxxxxx>, "EGit developer discussion (egit-dev@xxxxxxxxxxx)" <egit-dev@xxxxxxxxxxx>
Betreff: 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.

 

[1] http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2FresAdv_markers.htm

 

-Matthias