BTW, the checkout fails because for some reason is trying to checkout an old for that pull request (that was force-pushed). Sometimes it works, sometimes it doesn't.

I wonder if that is related to JENKINS-21980 ? That bug reports that polling can fail when a prior detached head commit no longer exists in the repository.

Hm, exactly the case quoted in the issue description does not have any detached commits, it is a normal pull request branch. With this specific branch I can reliably trigger the issue by just doing `git commit --amend; git push -f origin branch-name` with no actual changes. Every new job triggered in such way fails. But I can't reproduce it on any artificially crafted branch.

I thought that if the commit which was created prior to "git commit --amend" were seen by the Jenkins job, then after the "git commit --amend" that prior commit would now be "detached" because there are no longer any references to the prior commit.

I'm not a gerrit user, so I may misunderstand the use cases, but I'm accustomed to "git commit --amend" leaving an "orphan" commit in the git reflog.

Yeah, there is one. But I am not passing it to job manually, where it could possibly take the hash from? It is not referenced from any of branch commits anymore.

I thought that the git plugin remembered the SHA1 of the preceding commit it processed so that it could use that earlier SHA1 to generate the list of changes. If the SHA1 of the preceding commit was in the Jenkins job, then was somehow removed, it seems like that might cause the failure you're describing.

Is there any chance the job moved from one node to another between the passing and the failing run?

Was the workspace wiped between the passing and the failing case? If it was wiped, then the plugin might remember the SHA1 which no longer exists in the newly cloned repository.

Yeah, that's what JENKINS-21980 seems to be suggesting, that Jenkins remembers the hash of the last build (now detached) to check if there are changes or not.

Shouldn't it be present in reflog of local copy then? git reflog | grep 58ef has shown me nothing.
Or it is last successful build?

I think it should have been present in the repository reflog, unless the repository was wiped from one job to the next. At a minimum, that SHA1 should be somewhere in the Jenkins jobs directory, since the value needs to be remembered on disc somewhere.