| Re: [egit-dev] Commit Validation |
|
Agreed. Still we should have a plan in mind. Not that there is a lot of effort implementing things, and in the end we discover that commit messages
cannot be validated that way (the original request), or that it’d require touching JGit/EGit in areas where we better shouldn’t for this feature. Cheers, Markus Von: Matthias Sohn [mailto:matthias.sohn@xxxxxxxxx]
I think validators should just create markers and EGit should allow to configure which markers shall raise warnings or block command execution when jgit commands are invoked. We could start by first adding a way to configure which markers should raise a warning or block commit when commit operation is started. This could be tested e.g. using compiler warnings or compile errors. Then we can incrementally add more validations to create other markers and enhance configuration to enable intercepting additional commands, e.g. "Add to Index". -Matthias On Mon, Mar 16, 2015 at 11:02 AM, Duft Markus <Markus.Duft@xxxxxxxxxxxxxxxx> wrote: Hey, OK, Markers might have some advantages, and I like the possiblities that open up there.
However we still do need a vast amount of hook points in EGit (and JGit) to allow validation of different things in different locations – for example the commit message; how would that fit into this kind of infrastructure? Would validation have the possiblity
to abort a commit (like jgit hooks)? Or does it “only” create markers and EGit “listens” to certain categories of them (to not even start the commit process)...? Cheers, Markus Von: Matthias Sohn [mailto:matthias.sohn@xxxxxxxxx]
On Fri, Mar 13, 2015 at 1:02 AM, Andrey Loskutov <loskutov@xxxxxx> wrote: 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. I think that's not true, we listen to resource modifications which drive incremental IndexDiff updates, that's actually what keeps staging view up-to-date. Which problem do you mean ? So if EGit validators listen on IndexDiff changes like staging view does I think we have a nice way to trigger validation. This would only be done on resources tracked in a git repository shared with the EGit team provider. If e.g. a project is disconnected from EGit we should clear the respective problem markers.
yes, exactly I want to show problems as soon as possible. E.g. if the user saves a file tracked by EGit which contains trailing whitespace the corresponding indexdiff would change,
an EGit validator could recognize there's trailing whitespace and create a problem marker. As soon as the user fixed this and saved the affected file the indexdiff would change again and EGit would revalidate the file and remove the problem marker if validation is ok. Another thing we could get from integration with problem markers is that it gives us a way to enable validations based on problem markers created by builders which don't need to be integrated directly with EGit. E.g. we could configure EGit to validate that only compilable code can be committed. So we could show a warning on commit "There are compile errors xyz do you really want to commit this changes ?" Or "you have compiler warnings abc".
yes, I think we should raise problems as soon as possible, e.g. if you save a file with trailing whitespace I think it's better to be informed about that immediately than to defer this until commit. -Matthias 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 |