Repo history changed — what the baseline banner means

For: all
Tier: free+
Time: ~3 min

Why you'd do this

You saw a red banner on a repository page that says "Repo history changed". This chapter explains exactly what triggers it (force-push, filter-branch, migration, accidental wrong-repo sync), what doesn't (normal daily commits), and what clicking "Acknowledge new baseline" actually does — including the permanent audit-log entry. Read this before clicking Acknowledge if you're not sure why the banner appeared.

Before you start

You see the red baseline-changed banner on a repo page
You have terminal access to verify what cl_sync reported (optional, but recommended before acknowledging)

Step 1

TL;DR

The banner means your repo's first (root) commit SHA changed.
That happens ONLY when git history is rewritten — force-push to main, git filter-branch, git filter-repo, repo migration, or accidental fork.
It does NOT appear on normal git commit + git push. Daily development won't trigger it.
If you recognise the change as something you did intentionally, click Acknowledge new baseline (owner only). One click, done.
If you don't recognise it, check you're scanning the correct repository before clicking anything.

Step 2

What ComplianceLint is checking

Every time you run cl_sync, the scanner sends two commit SHAs to the dashboard:

first_commit_sha — the very first commit of your repo (the root). Stays the same forever unless someone rewrites history.
head_commit_sha — the latest commit. Changes every push.

The dashboard stores the first_commit_sha the first time it sees your repo. On every subsequent cl_sync, it compares the incoming SHA against the stored one:

Same → silent, banner doesn't appear.
Different → banner appears with both SHAs shown side-by-side.

Step 3

What causes a baseline change

Five real-world causes:

| # | Cause | How likely on a healthy repo | |---|---|---| | 1 | git push --force that rewrites the root commit | Rare — usually intentional cleanup of a brand-new repo's first commit. | | 2 | git filter-branch / git filter-repo to remove leaked secrets / large files | Once-per-repo-lifetime maintenance. | | 3 | Repo migration — clone-and-recommit, GitHub → GitLab, etc. | Once when migrating. | | 4 | Accidental fork — cl_sync from a wrong-clone directory | Almost-never; would mean you're in ~/other-org/repo/ instead of ~/my-org/repo/. | | 5 | Re-init — rm -rf .git && git init | Almost-never; only if you deliberately blew away your history. |

What does NOT cause the banner:

Adding new commits (any number, by any author)
Merging PRs
Squash-merging
Renaming branches
Pushing to a different branch
Rebasing on top of main (only rewrites your local branch, not main's root)

If you're seeing the banner without doing any of items 1-5 above, that's a real red flag — usually means you cl_sync-ed from the wrong directory.

Step 4

What "Acknowledge new baseline" does

Owner-only button. Clicking it:

Writes the new first_commit_sha to the dashboard as the new baseline.
Logs a repo_fingerprint_change entry in your audit trail with both SHAs, the timestamp, and your user ID. This is permanent. It survives even if you re-acknowledge later, so auditors can always see the change happened.
Removes the banner.

Acknowledging is irreversible from the UI. If you acknowledged a baseline change that was actually a wrong-repo cl_sync, the original baseline SHA is recoverable from your audit log — contact support if you need to restore it.

Members (non-owners) see the banner but cannot acknowledge — only the repo owner can. This is for legal accountability: a baseline change can mask a compromised history, so only the owner takes responsibility.

Step 5

What to check before clicking Acknowledge

Right repo? Run pwd in your terminal where cl_sync ran. Confirm it matches the repo you intended.
Right remote? git remote -v — is the origin URL the one you expected?
Right branch? git rev-parse --short HEAD against what the banner shows. If they don't match the banner's "now" SHA, your cl_sync ran from a different branch.

If all three check out, the baseline change is real and intentional. Acknowledge and move on.

If anything looks off, don't acknowledge yet. Investigate first. The banner stays up indefinitely until acknowledged, so there's no pressure.

Step 6

What's in the audit trail

Every baseline-change event records:

previously_recorded_sha — the old root
acknowledged_first_commit_sha — the new root
acknowledged_by — owner's user ID + email
acknowledged_at — UTC timestamp
IP address of the acknowledge request

You can view these in the dashboard's audit log section. Compliance teams routinely ask for this trail during external audits.

What can go wrong

Banner appears every day even though I'm only doing normal commits — Normal git commit + git push doesn't change first_commit_sha. If you genuinely see the banner daily, the most likely cause is cl_sync running from the wrong directory (e.g., a stale clone or a different fork). Run pwd + git remote -v in the directory where cl_sync was invoked to confirm. If they look right but the banner persists, email support@compliancelint.dev with both SHAs.
I accidentally acknowledged a baseline change that was actually a wrong-repo sync — The original SHA is preserved in your audit log (it never gets deleted, even on re-acknowledge). Email support@compliancelint.dev with your repo ID; support can restore the original baseline. Don't try to cl_sync from the correct directory in the meantime — it'll trigger a NEW banner that you'd then need to compare against, complicating support's restore.
Only the owner can acknowledge — what if the owner is unavailable? — The owner is the only role with legal accountability for accepting a history rewrite. If you need to transfer ownership before acknowledging, the current owner does it from Repo Settings → Transfer Ownership. If the owner has left the team entirely, email support@compliancelint.dev with proof of legitimate access (audit-trail entries from the previous owner inviting you, for example) and we can transfer ownership manually.

Last updated: 2026-05-13

Repo history changed — what the baseline banner means

For: all
Tier: free+
Time: ~3 min

Why you'd do this

Before you start

You see the red baseline-changed banner on a repo page
You have terminal access to verify what cl_sync reported (optional, but recommended before acknowledging)

Step 1

TL;DR

The banner means your repo's first (root) commit SHA changed.
That happens ONLY when git history is rewritten — force-push to main, git filter-branch, git filter-repo, repo migration, or accidental fork.
It does NOT appear on normal git commit + git push. Daily development won't trigger it.
If you recognise the change as something you did intentionally, click Acknowledge new baseline (owner only). One click, done.
If you don't recognise it, check you're scanning the correct repository before clicking anything.

Step 2

What ComplianceLint is checking

Every time you run cl_sync, the scanner sends two commit SHAs to the dashboard:

first_commit_sha — the very first commit of your repo (the root). Stays the same forever unless someone rewrites history.
head_commit_sha — the latest commit. Changes every push.

The dashboard stores the first_commit_sha the first time it sees your repo. On every subsequent cl_sync, it compares the incoming SHA against the stored one:

Same → silent, banner doesn't appear.
Different → banner appears with both SHAs shown side-by-side.

Step 3

What causes a baseline change

Five real-world causes:

What does NOT cause the banner:

Adding new commits (any number, by any author)
Merging PRs
Squash-merging
Renaming branches
Pushing to a different branch
Rebasing on top of main (only rewrites your local branch, not main's root)

If you're seeing the banner without doing any of items 1-5 above, that's a real red flag — usually means you cl_sync-ed from the wrong directory.

Step 4

What "Acknowledge new baseline" does

Owner-only button. Clicking it:

Writes the new first_commit_sha to the dashboard as the new baseline.
Logs a repo_fingerprint_change entry in your audit trail with both SHAs, the timestamp, and your user ID. This is permanent. It survives even if you re-acknowledge later, so auditors can always see the change happened.
Removes the banner.

Step 5

What to check before clicking Acknowledge

Right repo? Run pwd in your terminal where cl_sync ran. Confirm it matches the repo you intended.
Right remote? git remote -v — is the origin URL the one you expected?
Right branch? git rev-parse --short HEAD against what the banner shows. If they don't match the banner's "now" SHA, your cl_sync ran from a different branch.

If all three check out, the baseline change is real and intentional. Acknowledge and move on.

If anything looks off, don't acknowledge yet. Investigate first. The banner stays up indefinitely until acknowledged, so there's no pressure.

Step 6

What's in the audit trail

Every baseline-change event records:

previously_recorded_sha — the old root
acknowledged_first_commit_sha — the new root
acknowledged_by — owner's user ID + email
acknowledged_at — UTC timestamp
IP address of the acknowledge request

You can view these in the dashboard's audit log section. Compliance teams routinely ask for this trail during external audits.

What can go wrong

Banner appears every day even though I'm only doing normal commits — Normal git commit + git push doesn't change first_commit_sha. If you genuinely see the banner daily, the most likely cause is cl_sync running from the wrong directory (e.g., a stale clone or a different fork). Run pwd + git remote -v in the directory where cl_sync was invoked to confirm. If they look right but the banner persists, email support@compliancelint.dev with both SHAs.
I accidentally acknowledged a baseline change that was actually a wrong-repo sync — The original SHA is preserved in your audit log (it never gets deleted, even on re-acknowledge). Email support@compliancelint.dev with your repo ID; support can restore the original baseline. Don't try to cl_sync from the correct directory in the meantime — it'll trigger a NEW banner that you'd then need to compare against, complicating support's restore.
Only the owner can acknowledge — what if the owner is unavailable? — The owner is the only role with legal accountability for accepting a history rewrite. If you need to transfer ownership before acknowledging, the current owner does it from Repo Settings → Transfer Ownership. If the owner has left the team entirely, email support@compliancelint.dev with proof of legitimate access (audit-trail entries from the previous owner inviting you, for example) and we can transfer ownership manually.

Last updated: 2026-05-13

Repo history changed — what the baseline banner means

Why you'd do this

Before you start

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

What can go wrong

Related

Repo history changed — what the baseline banner means

Why you'd do this

Before you start

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

What can go wrong

Related