Persist "Hide whitespace" preference across PRs

[madisonscott]

Select Topic Area

Product Feedback

Body

Hey team, thanks for all your hard work!

What are your thoughts on persisting the "Hide whitespace" preference in diff view settings across PRs, as the Unified/Split preference is persisted? I pretty much turn "Hide whitespace" on for every diff I look at, so it'd be nice to only ever do that once :)

Upon searching for similar discussions, I found an older thread that mentioned that this setting is intended to store your preference per-diff. To maintain that functionality, "Hide whitespace" could be added as a user-level setting, defaulting to that value when looking at a PR for the fist time, then still allowing it to be set a t a per-diff level on the diff itself.

Thanks for considering!

[alexander-dermicus]

Note that this proposal already has a lot of support in the older thread: https://github.com/orgs/community/discussions/5486

[EskeRahn]

Personally I believe it would be even better if it was possible to set per filetype, as not ALL filetypes has whitespaces as pure cosmetics.

But ignoring whitespaces should also be coupled with not seeing solo { and } with a particular indentation as a good match for synchronisation. that causes bad syncs for e.g. C# and similar.

[ardicoetzee]

Yes, please add this, at least on a per-user level.

[mlafleur]

At a minimum, the "Show Whitespace" toolbar button should always be visible. It shouldn't be markedly easier to show whitespace than to hide it.

[pcnova]

THIS HERE! 🙏🏼

[cupcakearmy]

Reviewing code is a BIG part of the time i spend on github. Hiding whitespace is such a vital feature, i don't unterstand how this cannot be a priority. You already have the functionality, just persist it 🙏

[NicholasMTElliott]

My workflow literally involves manually turning on this flag on every single PR I do, because the vast majority of files I review the white-space does not matter.

[patrickholley-asurion]

It's amazing that a website literally for computer programmers can cause so much disruption in a programmer's flow. Please add this as a persistent option, it is annoying and slows me down having to check it every time.

[Rylab]

One more vote to please oh please make this a persistent user-level (and/or repo-level) setting! It's quite rare that whitespace changes matter in our workflows; swapping the default to ignore it, would save so much time.

[ardicoetzee]

A friend directed me to this as an interim solution: https://chromewebstore.google.com/detail/git-well-soon/ehpeaofieafibmhiagianfjjblpnmbdo

I.e. A chrome plugin that does exactly what we want!

[alexander-dermicus]

Great workaround! Thanks for sharing!

[HarryCruse-Kaluza]

It wants permission to "Read and change all your data on all websites". Not sure why it would need such a huge amount of access

[atkeranov]

A dev could literally implement this in a day at max. Now imagine how many human work hours are wasted by developers coming here to read through this thread, vote, and comment.

[EskeRahn]

My guess would be that it is not the work load of the hack that is the issue....

IMHO implementing it as suggested surely would be better than what we have currently for many (including me), but really would be a inadequate hack/workaround for a deeper problem in
a) distinguishing logic and cosmetic changes, and
b) finding good ways to display these differences.

For the code part of say a .cs file spaces/indentions would be purely cosmetic, but inside a string value in the same file they might be important, with undesired nasty side effects, and thus not ignorable. and really ought to be visible to a reviewer, to catch a crucial system breaking typo!

So to do a logical diff without risk of false positives or false negatives some 'compiling' would be needed to decode each file into its logical components, including first detecting its programming language correctly (relying on the file extension might not be enough), before a compare can be safely done.
Maybe by the help af a compiler / de-compiler pair??

...And next comes thinking up a clever way of actually displaying the found logical differences between two files that char by char seems very different, but are close to logically identical (as we currently have it with spaces, but could be different line splittings as well)

So certainly not something pulled off in a single day....

[drwharris]

My guess would be that it is not the work load of the hack that is the issue....

IMHO implementing it as suggested surely would be better than what we have currently for many (including me), but really would be a inadequate hack/workaround for a deeper problem in a) distinguishing logic and cosmetic changes, and b) finding good ways to display these differences.

For the code part of say a .cs file spaces/indentions would be purely cosmetic, but inside a string value in the same file they might be important, with undesired nasty side effects, and thus not ignorable. and really ought to be visible to a reviewer, to catch a crucial system breaking typo!

So to do a logical diff without risk of false positives or false negatives some 'compiling' would be needed to decode each file into its logical components, including first detecting its programming language correctly (relying on the file extension might not be enough), before a compare can be safely done. Maybe by the help af a compiler / de-compiler pair??

...And next comes thinking up a clever way of actually displaying the found logical differences between two files that char by char seems very different, but are close to logically identical (as we currently have it with spaces, but could be different line splittings as well)

So certainly not something pulled off in a single day....

The functionality exists already. The only thing being asked is for a users to be able to have their preference to have it ON by default be remembered.

[EskeRahn]

@drwharris, Did you even read what I wrote, and what it was a comment to?

[drwharris]

I did and you have a valid point, however I use this existing functionality a lot and I use it knowing these limitations. And while a small inconvenience, I would like the option to default it to on.

[EskeRahn]

So you might have noticed that I started by saying that it for me too would be better than what we got now....

[johngallagher]

Please implement this. The previous thread has many comments. I heard devs complaining about this 3 years ago. It's 2024 and you have the backing of Microsoft. Please implement this.

[nelsondude]

This would be amazing to have! How can we get this feature prioritized? I find myself reviewing large PRs way too often, only to realize that its 95% whitespace changes. My company has strict policies on chrome extensions so that is not a viable option unfortunately.

[rgallagherab]

+1 on request for this user-level setting to be added.

[erorcodes]

This is one of the most annoying daily things I do (and that says a LOT) so please please prioritize 🙏

[armadsen]

Yet another request for this. I've written my own AppleScript to add ?w=1 to the URL with a keyboard shortcut in Safari, but it sure would be nice if persisting this were a GitHub feature.

(AppleScript below if anyone wants it. I use the excellent FastScripts to give it a keyboard shortcut.)

tell application "Safari"
	set currentDoc to front document
	set theWindow to window 1 where its document is currentDoc
	tell (current tab of theWindow)
		set URL to URL & "?w=1"
	end tell
end tell

[learn2reid]

Please add this!

[Aynekko]

Why is this still not implemented yet! It's a simple option and everybody wants it, PLEASE! I want to view commits with whitespace hidden by default. Please add a check in user profile for this, or something. I beg you!

[reneleonhardt]

Interestingly enough, the GitHub diff doesn't show Git whitespace errors anymore (file contained no trailing line break before the commit)... maybe it's hiding whitespace a bit too much now 😄

[s-robertson]

I was so tired of having to turn off whitespace changes on every PR that I wrote a Chrome extension that just does it for every diff page on GitHub. Please let us just choose the default value for this for ALL PRs so I can stop this madness.

https://github.com/s-robertson/github-ws

[abedolinger]

worth mentioning this works for firefox too!

[petevb]

I agree it'd be great to set this by default. Meantime, you can add this as a bookmarklet:
javascript:(function(){var u=new URL(location.href);if(u.searchParams.get('w')==='1'){location.href=u.toString();return;}u.searchParams.set('w','1');location.href=u.toString();})();

[Entroper]

IMO, the pull request page is the single most important page on all of GitHub. It's where the act of collaboration actually happens in the repository. The diff view is the most important tab on that page. And this is a really irritating thorn in the side of everyone looking at a diff.

[PfunnyGuy]

PLEASE add this. Right now the existing setting doesn't work if you have a large diff. I click "Load Diff" link because "Large diffs are not rendered by default." and it does NOT ignore whitespace. Only what is actually visible when I click the option gets whitespace ignored. This implementation is so incredibly lazy! It makes reviewing some files take an order of magnitude longer. You're a tool maker, please improve your tool!

[danny-pflughoeft]

Absolutely wild this request has been open so long. Do Github devs not use their own product?

[3htomit]

@willsmythe, as you answered the previous thread, can you please give us an update on this long running and highly expected request ?

[dtitov]

Bump. It's mind-blowing how such a simple feature, requested by so many people, is ignored for such a long time...

[youssef-lr]

Workaround in the meantime https://chromewebstore.google.com/detail/github-whitespace/fnpkdafamnbjoldglihkjjdicofghccm

[mateusfccp]

Imagine using Google Chrome.

[youssef-lr]

You can install it on any chromium fork. I use Brave.

[mateusfccp]

It's just stupid that this was not yet implemented. The original post is from 2021, and this is from 2023 and we have no answer. Can't expect much from Microslop.

[EskeRahn]

What is stupid here is not that it is not implemented, but that they do not bother to try to explain WHY they do not implement it.

It CERTAINLY would most often be VERY convenient, but as I tried to explain above, I too would hesitate implementing it blindly, as it MIGHT make people overlook breaking changes that an ignore white-spaces might have missed as crucial. It requires understanding of the text to know if white-spaces matter or not. Maybe an AI variant can give us that distinction between important and unimportant white-spaces.

ADD:
When we actively have to choose to hide the white-spaces, that nuisance is a clear choice we make, so that they can not in any way be considered liable for something that breaks due to a change that was not shown in the diff-view. So my guess would be it is a lot about cover-our-a..es that is in play here.

[luchillo17]

For the most part white-spaces only matter in 2 situations, inside strings (template strings, plain strings), and in indentation based languages like Python, other than that I don't see whitespaces as significant in a diff, especially if you have auto format tools like prettier taking care of the white spaces.

[joshuaandrewhoffman]

Absolutely floored that this feature is STILL not implemented in the year-of-our-lord-2026 despite the overwhelming demand by the community at large for over five years.

Just let us write the damn feature for you at this point.... It's a persisted settings toggle that changes a query string for goodness sake

[vamnguyen]

Thanks Github :)

[luongvo]

Up, I really need this feature :)