Git cannot-pull-with-rebase-unstaged-changes Git refused a pull configured for rebase because tracked files carry uncommitted edits.

dev@local: ~/project — git

dev@local~/project$git pull --rebase

error: cannot pull with rebase unstaged changes

Diagnostics Translation

Git refused a pull configured for rebase because tracked files carry uncommitted edits.

waiting for resolution...

LowVersion Control System

Reviewed for reference consistency: August 11, 2026

Code is Safe

SECURE

Git has paused the operation to protect your code. No data has been lost or corrupted.

What To Know

The fetch completed but the configured rebase replay never started, because edits in tracked files gave Git no clean baseline to replay from.

Where Did It Fail?

Working Tree

Your local files

add

Staging Index

Prepared changes

commit

Local Repo

Commit history

push/fetch

Remote Server

GitHub/GitLab

The error involves the internal Git database or commit history structure.

Commands That Trigger This

$git pull --rebase

Running on a branch where a tracked file was edited but not staged

A scheduled or scripted pull that inherits pull.rebase=true while the checkout holds half-finished edits

Switching tasks mid-feature: edits left in the tree collide with an incoming rebase-style update

Technical Background

This guard comes from the rebase step of a pull, not from the fetch. The download of remote commits succeeds; what fails is the planned replay of your local work on top of them. A rebase moves commits one by one, and uncommitted edits could be swept into the wrong commit or lost mid-replay, so Git declines to start.

The message pairs with its companion line 'Please commit or stash them.' Neither phrase signals damage — the fetch already succeeded, and every local change still sits exactly where it was.

The same precondition backs direct rebases; the pull variant announces itself with 'cannot pull with rebase' because rebase was chosen by configuration rather than by an explicit rebase command.

Underlying Causes

pull.rebase is set to true in the repository, global, or system configuration

The pull command was invoked with an explicit --rebase flag

Modified tracked files were left in the working tree by an earlier task

A build or formatter touched tracked files after the last commit

Frequently Asked Questions

Yes. The failure happens after the fetch, at the point where Git would begin replaying your commits, so the remote-tracking branch is current once the command finishes.

Without --rebase or pull.rebase=true, a pull integrates by merge, and merging tolerates uncommitted changes unless the incoming edits touch the same files.

Stashing is the common detour, but committing the work first reaches the same state; either path hands the rebase a clean tree to run in.

Related Git States

local-changes-overwritten-by-mergeMedium

Git aborted the merge to protect uncommitted changes in your working directory.

stash-pop-conflictMedium

Reapplying a stash hit conflicts, and the stash entry was deliberately kept.

rebase-in-progressLow

You tried to run a Git command while a previous rebase operation is still paused.

cannot-rebase-unstaged-changesLow

Git declined to start a rebase while the working tree holds unstaged modifications.