-
Suggestion
-
Resolution: Won't Fix
-
None
In the new PR experience, the "Ignore whitespace" option is moved under global settings.
In the Old PR experience, this option is available for each diff under ... option
This impacts some customers who generally keep the "Ignore whitespace" option 'off' as per their workflow. However, they need to enable the option while reviewing a file with lot of whitespaces.
When the user is in the middle of reviewing a PR, if he sees a huge file with tons of whitespace changes, he has to scroll all the way to the top of the PR to enable the option and then go back to file which he was reviewing. This is annoying to the user.
[BCLOUD-20108] Need the "Ignore whitespace" option for each diff in the PR
We show whitespaces in diff as standard setting. We need to hide whitespace changes occasionally. Example:
<div> // Tons of lines here <small>Change here</small> // Tones of lines here </div>
Now if someone will just remove surrounding div `// Tons of lines here` will be moved to the right and PR starts to be huge and `Small change` unreadable.
We used to use 'Ignore whitespace' in such cases. Now this is ridiculous, to scroll up, open modal, change setting, save, find where I was before and most fun part: remember to go back and switch everything back to not ignore WS next time!
For my team this "feature" (removing fast access to commonly used functionality) is something that should never happen.
Now we will "GATHERING INTEREST" for next few years like it is always here, just because some UI designer had brilliant idea.
Like for stupid likes (1 year of waitng), marking comment as resolved (from 2013) or pre hooks (2014).
More generally, ignoring whitespace does not make it go away. Spurious whitespace will still grow diffs unnecessary and foul up annotation. Keeping diffs concise is critical to good software development and avoiding spurious whitespace is an important part of that.
Having the option as a per-user option rather than a per-PR option, means a user may switch this option on and then forget about it, increasing the chance that they add spurious whitespace in later pull requests.
It may be that there are use cases where additional whitespace is not an issue, but I struggle to see that they are common enough to merit having this feature, given its footgun capacity.
Rather, I would suggest that you move this option to the user preferences page and re-introduce a per-PR option that would take its cue from the user preference.
Either way, we need a prominent indication that whitespace is ignored.
After reviewing this issue, we determined that it was low priority and unlikely to be worked on in the near future. We appreciate your input, but want to be transparent about our decision to not fix this right now.