Cristian Cureliuc I replied here and here. I am not working on this bug currently. I don't expect to work on this bug in the near future.
I don't like the plugin behavior, but it is a pragmatic behavior, selected due to command line git behavior. When command line git is asked to fetch into an existing directory with existing files, there are many scenarios where command line git will fail the fetch. Rather than fail the fetch, stop the job, and report an error to the user, the git plugin decided many years ago to remove pre-existing files if it detected what appeared to be an incomplete or incorrect initial workspace.
The earlier comments in the bug report show the difficulty I had duplicating the problem because that code is only executed on the path that creates the initial workspace. With a freestyle job, it can be duplicated by intentionally forcing an incorrect workspace location (bad practice) or by inserting a pre-SCM step which creates a file in the workspace before the git repository is fetched. Pipeline jobs can see the behavior by adding files to the workspace before the git repository is fetched.
I've intentionally not modified this code. Changing the behavior of the git plugin for this case won't give command line git (or JGit) the ability to reliably fetch into a directory which includes unpredictable content. If the git plugin adds an option to "allow initial fetch to non-empty directory", there will still be use cases which can't be addressed because command line (or JGit) initial fetch fails with certain content in a directory.
I'm sorry to hear you say:
This kind of problem makes jenkins not interesting for us anymore and we are considering alternate solutions.
Unfortunately, if I change the default behavior, I'm confident that I'll discover far more users who depend on the current behavior. They will assert strongly that the job of their continuous integration server is to checkout the code they said to checkout, and to continue behaving the way it did in the past.
If an optional behavior is added, then that option needs to be selected by the user, and it then needs to be maintained and tested across multiple releases and multiple use cases. I haven't seen enough gain from the proposed optional behavior to justify the complexity and maintenance challenges of adding another optional behavior to the "Advanced checkout" options.