Depending on the type of Git Client you are using (I hate the command line, I use Eclipse Git or TortoiseGit – my preference), the way how files are committed differs. Normally with git command line you would first stage all files and then commit them. If you stage them and then run precommit, it works fine, as the "changed" and "added" and other stati are ignored and its still confirmed as "clean". After the pre-COMMIT task you finally commit.
But Git GUIs don't have the concept of staging. You can (similar to Subversion) add files and delete files, but when you modify a file you cannot explicitely "stage" the change. What you do is to open the commit GUI, put checkboxes on all files you want to commit and then the GUI triggers a stage and commit directly after each other.
In this workflow, the precommit check of course complains about "modified" files.
This is the reason why the Ant task does have 2 modes:
- The strict mode which forbids any change in the working copy, so it must be 100% clean. By default, Ant only runs this if the property "is.jenkins.build" is enabled. The reason for that is to detect any change in the working copy caused by running the Jenkins CI (like temporary files munging around).
- The default "committer/developer" mode: In this case the working copy check only complains about "untracked" or "missing" files. So a committer who changes some files can still pass precommit. If he adds a new file, he has to add it to the index, so its not untracked. But generally normal modifications of working copy are allowed.
Please add this back. There was a reason why I set up the check-working-copy Ant task like it was.
If others aggree, i'd like to change the task so it has two modes:
- Full clean mode (for CI builds), enabled only if it's a CI build – we should maybe add some tasks like "jenkins-hourly"on root project that enables this mode
- Developer mode (default), that does not care about "modified" files.