Checking out a dedicated commit fails after using setNoCheckout(true)

[Waldleufer]

Version

7.1.0.202411261347-r

Operating System

Windows

Bug description

Hello 👋

clone .setNoCheckout(true) is conflicting with checkout .setForced(true)

I am not 100% sure if that is a bug, but it quite feels like it.

Actual behavior

So I did something along these lines:

        final var clone = Git.cloneRepository()
            .setURI(repo.getUrl())
            .setDirectory(outputPath.toFile())
            .setNoCheckout(true)
            .setCredentialsProvider(buildCredentialsProvider(repo));

and afterwards I tried to

        try (final var git = clone.call()) {
            final var repository = git.getRepository();
            final var commitSha = resolve(repository, repo.getRevision());

            log.trace("Checking out commit {}", commitSha);
            git.checkout().setName(commitSha).call();

Which didn't work and yielded a org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict with files

Since the directory in which I want to clone is empty at that point in time due to the .setNoCheckout(true) I thought, I could just ignore this by doing

            git.checkout().setName(commitSha).setForced(true).call();

However, because of this code here failing when a file (that is already not there) can not be deleted, that didn't lead to the expected outcome.

jgit/org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java

Lines 1309 to 1311 in 89f5425

	if (!conflict.delete())
	throw new CheckoutConflictException(MessageFormat.format(
	JGitText.get().cannotDeleteFile, c));

Expected behavior

The checkout to succeed, because there are no conflicting Files

Relevant log output

Other information

The repository used was the jgit repository. The reference used was the commithash of the tag v7.1.0.202410012040-m1 However private/public repo is not relevant for this bug.

Removing .setNoCheckout(true) lead to the checkout succeeding.