One common case of "Couldn't find any revision to build" is because the commit with the SHA-1 mentioned in the message is not available inside the workspace on the agent. If you can access the agent workspace after the job has failed, you could confirm that the SHA-1 mentioned in the message exists in the workspace on the agent. The command {{git log 22a341d6223157c1e1b2db792c26eb007f80d64a }} in the agent workspace should provide the same output on the Linux agent and the Windows agent.

If they don't have the same output on Windows and Linux, then the usage of the two workspaces may have been different. For example, sometimes an existing agent workspace is reused and it contains that SHA-1 and other times a new agent workspace is created and the SHA-1 is not available, either because the fetch did not copy it or because it does not exist in the central repository.

As a separate note, that might possibly be related, the message warning about git client older than git 1.8.4 and the message that the Linux agent is running on RHEL 7 may be indicators that the command line git version on the RHEL 7 machine should be considered for upgrade. RHEL 7 ships command line git 1.8 by default. That is a 6 year old version of command line git. I suspect that the command line git version on the Windows computer is much newer. Git 2.28.0 is the current release of command line git. It includes many capabilities that are not available in command line git 1.8 as shipped with RHEL 7.

The double quotes on Windows are not likely to be a problem. The Windows command interpreter treats the "^" character as a special character. When the git plugin passes the string

"SHA-1^{commit}"

to command line git on Windows, it must surround that argument in double quotes so that the "^" is not processed by the command interpreter as a special character.

Indeed, looks like the checked out copies are different.

Windows:
C:\jenkins\workspace\freestyle_checkout>C:\jenkins\tools\git\cmd\git.exe log 22a
341d6223157c1e1b2db792c26eb007f80d64a
fatal: bad object 22a341d6223157c1e1b2db792c26eb007f80d64a

Linux:
[vmtest@sofumrhel02 freestyle_checkout]$ git log 22a341d6223157c1e1b2db792c26eb0 07f80d64a
commit 22a341d6223157c1e1b2db792c26eb007f80d64a
Author: Build SAG
Date: Tue Sep 1 16:37:11 2020 +0200

But how is that possible since both configurations are starting from a clean workspace and the checkout job config is the same for both?

(and yes, our git client on the RHEL machines is significantly older that then windows one - the reason is that the newer windows client is easily installed using Jenkins zip auto-installers but GIT is providing zip binary distro only for Windows, looks like they ceased providing binaries zip for Linux: https://github.com/GoogleCloudPlatform/gcsfuse/issues/162)

The job definition you uploaded as config.xml includes the "clean before checkout" behavior but does not include the "wipe workspace" behavior. The "clean before checkout" behavior retains the existing git repository (the .git directory) but removes untracked files. It does that with the git clean -xfd command.

If the workspace had been previously populated with repository content, the "clean before checkout" does not remove that previously created content. The git plugin tries to reduce data transfer by retaining the git repository across multiple builds in the same workspace. You would need to add "Wipe workspace" to assure that the two workspaces have the same content.

If wipe workspace still shows a difference, then it is likely that there is a difference due to the two versions of command line git being used.

Alex Vasilkov did you find a solution to the issue? Should this be closed? If not, can you provide more details on the failure?

Making sure the workspace is deleted before starting the checkout operation worked for me.