Allow users to set "Hide whitespace changes" by default

[ovflowd]

This is a feature request that exists for 3 years (https://github.community/t/feature-request-option-to-always-hide-whitespace-changes-when-viewing-diffs/1896) and would be a very nice addition for GitHub.

The problem

Many users want to by default always "Hide whitespace changes" on Git PR diffs or GitHub code diffs in general.

The solution

• Allow a user-wide setting to "Hide whitespace changes" (And vice-versa, as a checkbox)

[golaod]

If not as a setting, then as part of a GET param or a cookie.

[zeitwidrig]

GET param already exists. Add ?w=1 to ignore whitespace changes.

[rbelling]

that works @zeitwidrig but you have to add it every time and it seems like it gets cleared when you navigate to another GH page

[WaKeMaTTa]

Sometimes I move code and the PR that I make seems very complex, but when you use "Hide whitespace changes" you can easliy realize that one change a couple of lines.

I would love to be able to configure this for each PR differently.

[EskeRahn]

I would claim that it would be better to have individual settings for file types, for the project.

As e.g. indentation is important for some file types.
Strictly it is the change in indentations that matters here, so if a large block is moved in/out, only the beginning and end of the block is interesting. For many file types we might want to completely ignore repetition of whitespaces.

[willsmythe]

This is partially addressed by a feature we shipped a few weeks ago: https://github.blog/changelog/2021-10-14-hiding-whitespace-is-now-remembered-for-each-pull-request/

GitHub now remembers "hide whitespace" for you on the pull requests you enable it on.

We explored other options including a user-level setting (and we may reassess in the future), but decided the right first step was to remember it for each pull request.

[chicken-suop]

This question is not answered. I would like this feature in 2024

[brett-adim]

Partially addressed !== addressed. This doesn't reduce the amount of work it takes to do a proper review.

[TD-DO]

Yes please implement this feature all the way

[johnc-ftl]

@willsmythe - This is not remotely close to addressing the issue. Even a per PR setting would be much better (b/c many PRs are hard to review without telling every participant to click a link with &w=1), but really this needs to be per repo.

[xbtmatt]

Could you please add this? I'd wager some 95%+ of diffs have 5x the amount of lines changed due to the indentation changing...

[aidantorrence]

Any updates?

[Pakon2543]

https://github.blog/changelog/2021-10-14-hiding-whitespace-is-now-remembered-for-each-pull-request/

[sethfri]

Hi @willsmythe, could you remove the shipped label from this discussion? The feature request here is for a per-user setting, applied to all PRs for that user. Are there any plans for this?

[fiddur]

It says @michellemerrill marked it as the answer; maybe they could remove that...

[vtopc]

I'm using https://chrome.google.com/webstore/detail/github-whitespace/fnpkdafamnbjoldglihkjjdicofghccm as a temporary fix for that.

[archon810]

The only problem is it doesn't let you view diffs with white space enabled anymore.

[cduflo]

https://chrome.google.com/webstore/detail/git-well-soon/ehpeaofieafibmhiagianfjjblpnmbdo allows a user override to view whitespace. Also works for github enterprise git.***.com

[serg06]

Thanks for the link! However it won't work for people whose companies block third-party extensions.

[rspringAya]

For the love of all that is good, thank you for that extension link! I've wasted so much time sorting through PRs when I forget to check "hide whitespace"...

Please please please GitHub, revisit this as a user setting!

[knodi]

It's mind-boggling that someone would let it persist per-PR and think they had done what was asked for.

Thank you so much for that extension!

[osdiab]

This seems to work for Firefox. https://addons.mozilla.org/en-US/firefox/addon/github-whitespace-disabler/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search Omar

…

On Wed, Apr 20, 2022 at 4:44 PM, Vilen Topchii ***@***.***> wrote: I'm using https://chrome.google.com/webstore/detail/github-whitespace/ fnpkdafamnbjoldglihkjjdicofghccm as a temporary fix for that. — Reply to this email directly, view it on GitHub <#5486 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAONU3UK7DRCXK5HLOGOPFTVF6YXNANCNFSM5DQBTCNA> . You are receiving this because you commented.Message ID: ***@***.***>

[mcskinner]

I would also prefer this setting exist at a per-user level. It is almost never useful to see whitespace changes and I have to turn this off consistently.

[CowDotDev]

Voicing support for a user-level setting to keep Hide Whitespace... it's nice to stay on the PR, sure, but working in a project where whitespace doesn't matter, and is also handled via Prettier/Eslint, this is really annoying to have to toggle it for every single PR.

Any are acceptable options in my mind:

• Remember at User Setting Level
• Remember at Repo Setting Level
• Remember at a Repo Setting Level, by User.

[cduflo]

My chrome extension solves for this problem until github decides to support this function: https://chrome.google.com/webstore/detail/git-well-soon/ehpeaofieafibmhiagianfjjblpnmbdo

[CowDotDev]

Note to any employees at GitHub that see this comment...

This is not a fix, having to download a random extension is a security risk - not trying to accuse the developer, just is a concern.
Clearly there is a continuous stream of vocal support for this type of update, I continue to urge you to reassess this ticket as unanswered. @willsmythe

[arjun-menon]

The permissions requested are too broad on this extension. Definitely not installing as it asks for permissions to read all websites, as well as browsing history.

[cduflo]

@arjun-menon it's been awhile since your comment, but I did go back to refactor the extension to require less permissions. Thanks for your feedback and apologies for the long delay!

[arjun-menon]

@cduflo I'm kind of just waiting for https://github.com/orgs/community/discussions/65597 to be implemented. Also, I use Firefox exclusively now, so I can't install Chrome extensions...

[Luc45]

@willsmythe are you aware of the negative feedback of the proposed solution? JFYI

[jlevitt]

Would love this to be a user setting.

[RenatoCoelho-BiggerPockets]

My team is still interested in this feature, and the "answer" doesn't address the issue.

[ughitsaaron]

This would honestly be so helpful and convenient. And as the marked comment states with the world "partially", this isn't, in fact, resolved.

[kkarthikeyan]

@willsmythe - not sure why this is marked as shipped while the issue remains. And you seem to be unmoved by all previous users comments to remove the answered and shipped labels. This seems very unresponsive on GitHub's part.

[osdiab]

Should just make a new issue/discussion, they’re probably just ignoring this since it says it’s resolved

[stravant]

I can't believe it's 2023 and this still isn't possible. Please implement it.

[EskeRahn]

This is a problem especially hitting C# (and similar) when using the quite common 'convention' of moving the
{
to the beginning of next line, as compare currently sees it as an important 100% synchronisation hit if the indentation matches.

If they, when syncing the two, gave a sole '{' (and '}' ) with any indentation the same (low) synchronisation weight, it will be much more likely to get the syncing right, and the urgent need for the feature they seem to refuse to implement would be almost gone.

In a more advanced version it could (for syncing purposes) consider a set of pure punctuation chars (braces, parentheses, comma... ) with any indentation as something logically 'belonging' to the and of the previous line. It would make it much more likely to get the syncing right.

Obviously it shall be displayed as in the file, I'm merely talking about the logic for syncing.

[daveatweaviate]

remember-the-setting-when-revisiting isn't a solution. Please allow a default 'hide whitespace' setting. If hide-reveal whitespace is already possible, why is adding a config setting hard?

[rbelling]

I assume because it requires changes to the account page to add that option and there currently isn't a good section for it, it would probably be something like "Your Code Review Preferences" but there isn't such a section yet. And it has to be applied to each PR you're looking at. And potentially be overwritten by the Pr-specific settings.

So, not trivial, and also probably not a big enough product priority given that we can already set it on a PR manually.

@willsmythe this would be a good one to bundle in a "Your Code Review Preferences" page when there is enough preferences for that account page to make sense. Any idea if this is in the roadmap?

[hikeeba]

Adding a toggle option is trivial, and GitHub isn't known for consistent or amazing UI design, so that shouldn't stop them. But it wouldn't suprise me if you're right that they can't figure out how to make this fit easily...

[RobertTheBlair]

My company just switched from Bitbucket to Github, and this is one of many quality of life features I am missing.

[daveatweaviate]

Make it exactly the same as split or unified view. That persists from PR to PR and it is already next to the per PR whitespace toggle. All that would change is to add whatever persistence they already use for the view to the whitespace toggle.

[szalapski]

I must agree. This seems like a no-brainer to make into a user setting. Please do so!

[alexander-dermicus]

A new discussion was opened on this topic: https://github.com/orgs/community/discussions/65597
Since this one is marked as shipped and answered, let's upvote that one instead. Maybe we get a response then.

[ManashviCode]

thanks