FetchCommand silently fails when a fetch error occurs

[aschott-looker]

Version

5.13.0.202109080827-r

Operating System

Linux/Unix

Bug description

If there is a stale git lock file in the target git repo and you invoke the FetchCommand in JGit, it returns a FAST_FORWARD result. This implies the command was successful even though it actually failed due to the lock file.

This behavior appears to be consistent if the fetch fails for other reasons as well. For example: https://bugs.eclipse.org/bugs/show_bug.cgi?id=564011

Actual behavior

If the fetch operation fails, it fails silently and returns a successful result (e.g. FAST_FORWARD).

Expected behavior

JGit should propagate errors upstream if the fetch operation fails. For example, in the case of the lock file being the root cause it should return LOCK_FAILURE.

Relevant log output

No response

Other information

No response

[adkatz]

How to repro:

1. Manually create a lock file for a branch, e.g. ~/test_repo/.git/refs/remotes/origin/main.lock
2. call FetchCommand

Something I noticed in this case is that calling <fetch_results>.getTrackingRefUpdate('refs/remotes/origin/main').getResult() returns FAST_FORWARD. According to this documentation there is a LOCK_FAILURE constant that should be returned in this case.

Could it be that the bug is that when there is a lock failure the lock status isn't being set properly? I believe that when status is REJECTED (like when local branch contains uncommited changes), the FetchCommand actually does raise an error when called.

[msohn]

Your repro proposal doesn't match what is described in the bugzilla bug 564011, there the fetch fails since a prefix of the ref (origin/release) already exists in the ref database; the creation of the new ref (release/v1.18) & all other refs from the fetch result are aborted.

Did you check if this problem still exists on master ? 5.13 is EOL, we cannot maintain umpteen releases in parallel. If you are still on Java 8 consider to update to a supported Java version. The next JGit release 7.0 will require Java 17.

[aschott-looker]

@msohn - Thanks for taking a look! I just updated the title / description of this issue to match the repro provided by @adkatz. If I understand the problem correctly, I believe the exact reason the fetch fails is less relevant. It has more to do with the fact that errors on fetch don't appear to get propagated upstream.

[sokai116]

This is a serious issue in Windows OS. When doing a git fetch, the lockLooseRefs(pending); in PackedBatchRefUpdate will return null if 2 branches have the same name but differ only in case, then the fetch silently fails.

[aschott-looker]

This ended up being an issue with our application wrapper code, not JGit itself, so closing this out.