Git PR Shows Hundreds Unexpected File Changes Fix

Git pull request unexpected changes often happen because the PR is being compared to an old merge-base (so Git diff shows hundreds of files) or because migration/noise (line endings, file-mode changes, or a history mismatch between forks) is making many files appear modified. Check the PR base and the branch ancestry with git merge-base / git diff to confirm, then fix by either rebasing/merging onto current master or (safest) creating a fresh branch from master and cherry‑picking or copying only your new file; normalize line endings with a .gitattributes if you see CRLF/LF noise.

Contents

• Why Git pull request shows unexpected changes
• How GitHub computes PR diffs (merge-base) — why “hundreds of files”
• Quick diagnostics — commands to run right now
• Safe fixes (clean branch, rebase, or merge) — step‑by‑step
• Line endings & file-mode noise: normalize the repo
• Pre-merge checklist and local merge simulation
• Sources
• Conclusion

Why Git pull request shows unexpected changes

So why does adding a single file result in a PR listing hundreds of changed files? Two common categories explain this: ancestry/merge-base issues and “noise” (line endings, file‑mode, whitespace).

• Merge-base / ancestry mismatch. A pull request is not simply “what changed in my last commit”; GitHub (and other Git hosts) shows the changes between your branch tip and the common ancestor commit where your branch diverged from the target branch. If your feature branch was created from a very old commit or from a different branch, the diff will include everything added to the target branch since that ancestor — which can be hundreds of files. See GitHub’s comparing-branches docs and explanations about PR diffs and merge-bases for details (see About comparing branches in pull requests and Gearset explanation of PR diffs).

• Wrong base / fork history mismatch. If you opened the PR against the wrong base branch (or the fork/upstream histories differ because of a migration or a shallow copy), the merge-base might point far back or to a different commit graph — producing an unexpectedly large diff. You can change the PR base in the UI if needed: Changing the base branch of a pull request.

• Line endings, file-mode, or whitespace noise. Moving a repo between systems (Windows ↔ Linux) or cloning/mirroring can introduce CRLF vs LF differences or file permission (executable bit) changes that make whole files appear changed even when content is semantically identical. GitHub and Git treat these as differences unless you normalize them with .gitattributes or config settings (see GitHub’s guide on dealing with line endings and the Git attributes docs at git-scm gitattributes).

Migration scenarios (like moving from CodeShip to CloudBees without direct access to the original repo) are particularly prone to these problems because you may have recreated remotes, missed some refs, or changed commit ancestry during the copy — so double-check remotes and commit history before trusting the PR view.

How GitHub computes PR diffs (merge-base) — why “hundreds of files”

Short version: GitHub shows the diff between the PR branch tip and the common ancestor (merge-base) of the PR branch and the base branch. That means the PR contains everything the feature branch introduced since divergence, not just your last commit.

Useful commands and concepts

• Find the merge-base between your branch and master:

git fetch origin
git checkout your-branch
git merge-base HEAD origin/master

• Show the actual file list that will be compared (differences since the merge-base):

git diff --name-status $(git merge-base HEAD origin/master) HEAD

• Or use the three‑dot syntax which is equivalent:

git diff --stat origin/master...HEAD

(See the explanation of git diff --merge-base equivalence for the exact behavior: https://stackoverflow.com/questions/79630517/show-differences-between-commits-with-respect-to-a-base.)

If the merge-base is a commit from years ago, the list will include every change made in master since then plus whatever’s on your branch — which looks like “hundreds” of changed files even when you only added one file.

When histories have been rewritten (force pushes, rebases in the upstream repo, or a migration that changed commit IDs), your clone’s ancestry can be out of sync or incompatible with the remote you’re creating the PR against. That mismatch produces the same effect.

Quick diagnostics — commands to run right now

Run these in your local clone and inspect outputs. They’re safe read-only checks.

1. Confirm remotes and refs:

git remote -v
git fetch --all --prune
git branch -vv

2. See where your branch diverged from master:

git checkout your-branch
git merge-base HEAD origin/master # prints the merge-base SHA
git rev-list --left-right --count origin/master...HEAD
# output like "X Y" means X commits only in origin/master, Y commits only in HEAD

3. List the files the PR is actually including:

git diff --name-status $(git merge-base HEAD origin/master) HEAD
# or
git diff --stat origin/master...HEAD

4. Quick graph of history to look for odd ancestry:

git log --graph --oneline --decorate --all --boundary -n 100

5. Check for whitespace/line-ending noise:

git diff -b origin/master...HEAD | head -n 200 # -b ignores whitespace amount differences
git status --porcelain

Interpreting results:

• If git merge-base points to a very old SHA, you probably branched from an old commit.
• If the file list shows only line-ending/permission-only changes (look at the diff hunks), then line endings or file-mode are the problem.
• If git rev-list --left-right --count shows many commits on both sides but your local master differs from the remote master, you may be targeting the wrong remote or a fork with different history.

If anything here looks off, don’t merge yet — follow the safe fixes below.

Fix Git diff hundreds files: safe options (create clean branch, rebase, merge)

Pick the approach that matches your comfort level and whether the branch is shared.

Option A — Safest and fastest: create a fresh branch from current master and add only your file
(Recommended if you only added a single new file and don’t need your old branch history)

1. Update local master and create a clean branch:

git fetch origin
git checkout -B master origin/master # reset local master to remote
git checkout -b add-cloudbees-config

2. Add the file (copy or checkout the file from your old branch):

git checkout your-old-branch -- path/to/workfile.xml # pulls file from the old branch
git add path/to/workfile.xml
git commit -m "Add workfile.xml + CloudBees config"
git push -u origin add-cloudbees-config

3. Open a new PR from add-cloudbees-config into master. That PR will contain only your new file.

Option B — Rebase your existing branch onto up-to-date master
(Cleans history; rewrites commits. Only do this if nobody else depends on the branch, or coordinate.)

git fetch origin
git checkout your-branch
git rebase origin/master
# resolve conflicts and continue with `git rebase --continue` as needed
git push --force-with-lease origin your-branch

Use --force-with-lease rather than --force to avoid overwriting someone else’s pushes.

Option C — Merge master into your branch (non-destructive)
(If you prefer not to rewrite history)

git fetch origin
git checkout your-branch
git merge origin/master
# resolve conflicts, commit
git push origin your-branch

Which one to choose?

• Need minimal risk and a clean diff? Use Option A (fresh branch).
• Want to preserve local commits and present a tidy linear history? Rebase (Option B).
• Want to avoid rewriting history and handle everything transparently? Merge (Option C).

If the PR was opened against the wrong base branch, simply change the base in the PR UI rather than trying to fix history — see changing the base branch.

Line endings & file-mode noise: normalize the repo

If diagnostics showed that many files are different only because of CRLF/LF or executable-bit changes, normalize the repository.

1. Add a .gitattributes (example):

# Normalize text files and enforce LF in the repo
* text=auto
*.xml text eol=lf
*.yml text eol=lf
*.sh text eol=lf

# Binary files (no EOL conversion)
*.png binary
*.jpg binary

See Git’s .gitattributes docs: git-scm gitattributes and GitHub’s guide on dealing with line endings.

2. Commit .gitattributes and renormalize:

git add .gitattributes
git commit -m "Add .gitattributes to normalize line endings"

# Modern approach:
git add --renormalize .
git commit -m "Normalize line endings"

# Older sequence (if needed):
git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"

Note: Renormalization can produce a large commit that changes many files; that’s expected. Coordinate with your team.

3. File mode (executable bit) issues:

git config core.fileMode false # on systems that don't respect Unix file modes

4. Re-run your PR diff after renormalizing — the noise should disappear.

Helpful reads on normalizing line endings: https://luispuerto.net/blog/2020/01/04/normalize-line-endings-files-git/, https://chapagain.dev/git-fix-differences-created-by-line-endings-in-files/, and https://graphite.com/guides/git-ignore-line-endings

Pre-merge checklist and local merge simulation

Before you click Merge, run this quick checklist:

1. Confirm the PR base is correct in the UI (target branch = master on the correct remote).
2. Run these to preview what will be merged:

git fetch origin
git checkout your-branch
git diff --name-status $(git merge-base HEAD origin/master) HEAD # files the PR will add/change

3. Simulate a local merge (safe preview):

git checkout master
git reset --hard origin/master
git checkout your-branch
git merge --no-commit --no-ff master # merges master into your branch, but doesn't commit
# run tests/build to verify
git merge --abort # undo the merge simulation

4. If the simulated merge looks clean (only intended file(s) modified, tests pass), proceed to merge the PR on the server. If not, do Option A/B/C from the fixes section.
5. If you must force-push after a rebase, use git push --force-with-lease and notify collaborators.

A final tip for migrations: if you recreated the repo on CloudBees (new remote) instead of pushing to the original repository, make sure the PR is actually targeting the expected upstream repository and not a fork or an old mirror — mismatched histories are the root cause in many migration cases.

Sources

• About comparing branches in pull requests — GitHub Docs
• Changing the base branch of a pull request — GitHub Docs
• Understanding delta file changes and merge conflicts in Git pull requests — Microsoft DevOps Blog
• Are your Pull Requests not showing what we expected? — Gearset Help Center
• What do the diffs in a GitHub Pull Request actually tell you? — Nebula Consulting
• git - gitattributes Documentation (git-scm.com)
• Configuring Git to handle line endings — GitHub Docs
• Normalize line endings on files for Git — Luis Puerto
• Git: Fix differences created by line endings in files — Mukesh Chapagain
• Ignoring line endings when using Git — Graphite guide
• Show differences between commits with respect to a base — StackOverflow
• GitHub pull request showing commits that are already in target branch — StackOverflow

Conclusion

A PR that lists hundreds of file changes after you added one file is usually a merge-base / history problem or noise from line endings/file-mode differences — common during repository migrations. Don’t merge blindly: inspect the merge-base with git merge-base and the actual diff with git diff origin/master...HEAD, then choose a safe fix (create a clean branch from current master and add the file, or rebase/merge correctly). Finally, normalize line endings with .gitattributes and run a local merge simulation to confirm the final merge will only bring the changes you expect.