git restore -p in Practice: Cleaning a Diff Without Losing the Real Change

Sometimes a task is very small, but after pushing it the pull request suddenly contains a much larger diff.

That happened to me recently. I changed spacing for one element on a page. The actual change was small, but during review I found unrelated whitespace, line breaks, and formatting mixed into the same files.

I could not simply restore the entire files from production, because those files also contained the change I needed to keep.

The real task became: remove only the accidental formatting changes while preserving the functional change.

git restore -p was exactly what I needed.

Before restoring anything, I inspected exactly what differed from the base branch.

The diff contained two different kinds of changes:

• the change I actually needed;
• unrelated formatting and whitespace.

That is why restoring the complete files was not appropriate. It would remove both the noise and the actual task.

If a file contained only an accidental change, restoring the whole file from the base branch would be simple.

But in this case the same file contained both the correct change and unrelated formatting.

I therefore needed something more precise than choosing between "keep the file" and "restore the file". I needed to decide what to do with each individual diff hunk.

The -p option means patch.

Git does not restore the complete file immediately. It shows the changes as separate hunks and asks what to do with each one.

When Git showed a hunk containing only accidental whitespace, line breaks, or formatting, I answered y.

That meant restoring that specific hunk from origin/production.

When Git reached the actual task change, I answered n so that change stayed in my working file.

In my case, these names made the actual task change easy to recognize among unrelated hunks.

The decision became very simple:

• only accidental formatting - y;
• the change required by the task - n.

That is the main advantage of git restore -p: I was working with individual pieces of the diff, not treating the file as one indivisible change.

After going through all hunks, I did not rely only on remembering my y and n answers. I inspected the result again.

A normal git diff shows the complete current diff.

git diff -w ignores whitespace changes. That is especially useful in this scenario because it lets me confirm that the functional change is still there after the formatting noise has been removed.

git diff --check provides another whitespace sanity check, while git status -sb gives me a concise view of the branch and changed files.

In my case, the unrelated formatting became visible only after the original change had already been pushed.

git restore -p does not rewrite an existing remote commit. It only changes the current files in my working tree.

After cleaning the files and verifying the result, I staged them, created a new commit, and pushed it.

The pull request then received another commit that removed the accidental changes without undoing the actual task.

If the history later needs to be reduced to one clean commit, that is a separate operation. At this stage, my priority was first to make the diff correct and understandable.

Of course I could have opened every file and manually restored spaces and line breaks.

But when one file contains the required change, accidental formatting, and several independent hunks, manual editing creates another risk: accidentally touching the code that should remain.

git restore -p already has the information I need. Git shows the exact piece of the diff, and I only decide whether to restore it from the base version or keep it.

It is a small Git command, but it solved a very specific problem.

The required change had already been made and pushed. Restoring the whole file would have removed it together with the unrelated formatting. Manually fixing every whitespace change would have been slower and less reliable.

git restore -p let me walk through the diff piece by piece and make one decision at a time: restore this or keep this.

The result was exactly what I needed: only the changes that had accidentally entered the pull request were removed, while the real task remained intact.