dotnet/runtime · error · RuntimeError

No JIT changes found starting with baseline hash

Error message

No JIT changes found starting with baseline hash

What it means

Thrown by process_git_hash_arg() when the git log command succeeds but returns zero commit hashes — meaning none of the last 20 commits starting from the baseline hash touched src/coreclr/jit/* or src/coreclr/inc/jiteeversionguid.h. The rolling build store only contains JITs built for commits that changed JIT code, so without any JIT changes, there is nothing to search for.

Source

Thrown at src/coreclr/scripts/jitrollingbuild.py:224

            raise RuntimeError("Couldn't determine baseline git hash")

        baseline_hash = stdout_git_merge_base.decode('utf-8').strip()
        logging.info("Baseline hash: %s", baseline_hash)

        # Enumerate the last 20 changes, starting with the baseline, that included JIT and JIT-EE GUID changes.
        command = [ "git", "log", "--pretty=format:%H", baseline_hash, "-20", "--", "src/coreclr/jit/*", "src/coreclr/inc/jiteeversionguid.h" ]
        logging.debug("Invoking: {}".format(" ".join(command)))
        proc = subprocess.Popen(command, stdout=subprocess.PIPE)
        stdout_change_list, _ = proc.communicate()
        return_code = proc.returncode
        change_list_hashes = []
        if return_code == 0:
            change_list_hashes = stdout_change_list.decode('utf-8').strip().splitlines()
        else:
            raise RuntimeError("Couldn't determine list of JIT changes starting with baseline hash")

        if len(change_list_hashes) == 0:
            raise RuntimeError("No JIT changes found starting with baseline hash")

        # For each hash, see if the rolling build contains the JIT.

        hashnum = 1
        for git_hash in change_list_hashes:
            logging.info("try {}: {}".format(hashnum, git_hash))

            # Set the git hash to look for
            # Note: there's a slight inefficiency here because this code searches for a JIT at this hash value, and
            # then when we go to download, we do the same search again because we don't cache the result and pass it
            # directly on to the downloader.
            coreclr_args.git_hash = git_hash

            if return_first_hash:
                # Just use the first one
                break

            urls = get_jit_urls(coreclr_args)

View on GitHub (pinned to 290d5ab72c)

Solutions

  1. Check 'git log --oneline -20 -- src/coreclr/jit/* src/coreclr/inc/jiteeversionguid.h' to confirm there are indeed no recent JIT changes.
  2. Pass -git_hash explicitly with a known JIT rolling build hash from the Azure store.
  3. Use 'jitrollingbuild.py list --global_all' to browse available JIT builds and pick a hash manually.

Example fix

# before: no JIT changes in recent history
python jitrollingbuild.py download

# after: specify a known good JIT hash
python jitrollingbuild.py list --global_all
python jitrollingbuild.py download -git_hash <hash_from_list>
Defensive patterns

Strategy: validation

Validate before calling

# Check for JIT changes before relying on auto-detection
import subprocess
baseline = subprocess.run(['git', 'merge-base', 'HEAD', 'origin/main'], capture_output=True, cwd=repo_path).stdout.decode().strip()
result = subprocess.run(['git', 'log', '--oneline', baseline, '-20', '--', 'src/coreclr/jit/*'], capture_output=True, cwd=repo_path)
changes = result.stdout.decode().strip()
if not changes:
    print('No JIT changes found in recent history. Pass -git_hash with a known build hash.')

Type guard

def has_jit_changes(repo_path: str, baseline_hash: str) -> bool:
    result = subprocess.run(['git', 'log', '--pretty=format:%H', baseline_hash, '-20', '--', 'src/coreclr/jit/*'], capture_output=True, cwd=repo_path)
    return bool(result.stdout.decode().strip())

Try / catch

try:
    process_git_hash_arg(coreclr_args)
except RuntimeError as e:
    if 'No JIT changes' in str(e):
        logging.info('Use jitrollingbuild.py list --global_all to find available builds.')
        sys.exit(1)
    raise

Prevention

When it happens

Trigger: After git log runs successfully (return_code == 0) but the decoded output is empty or produces no lines. change_list_hashes ends up empty, and line 224 raises the RuntimeError. This means the baseline branch simply has no JIT-source changes in its recent history.

Common situations: The current branch diverged from main a long time ago, and the 20-commit window from the merge-base doesn't include any JIT changes. The working tree is on a branch focused on non-JIT components (e.g., GC, runtime, tests). The repo layout changed and jit sources moved out of src/coreclr/jit/.

Related errors

AI-assisted analysis of dotnet/runtime@290d5ab72c (2026-08-06). Data as JSON: /api/errors/9d48af65e0249065. Report an issue: GitHub.