|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I can duplicate this bug. Thanks for the bug report.
The command line git implementation in the git client plugin performs a force checkout of the files associated with the SHA1 being built. That causes changes to tracked files to be discarded from one build to the next.
The JGit implementation in the git client plugin seems to not perform a force checkout of the files associated with the SHA1 being built. If there are changes in a tracked file, a new build with the JGit implementation leaves the modified file, rather than overwriting it with the version in the repository.
I duplicated your report by creating a job which performs a checkout, then appends text to one of the tracked files. Each time I run the job using the command line git implementation, it correctly resets the workspace to the state of the git repository, then appends a single line to the tracked file and completes successfully. If the repository were not being reset, the append would have caused those lines to accumulate, but there is always only one line visible at the end of the file.
Each time I run the job with the JGit implementation, the workspace is not reset and the new content to be added is appended to the target file.
One work around is to switch to the command line git implementation.
Does my description match the bug you're seeing, or is the bug I've detected something different than your problem?