4 ms·
Is this a commit? If so - is it normal to do indention changes and actual code changes in the same commit? Personally, I would first have committed the indent
by TekMol 3y ago
Is this a commit?
If so - is it normal to do indention changes and actual code changes in the same commit?
Personally, I would first have committed the indention changes and then did a second commit with the coded changes.
- cbsks 3y agoThe indentation changes are because of a removed if block.
- db48x 3y agoIf you look closely, you'll see that it's not merely an indentation change. The bulk of the function used to be inside a large condition, but that has been changed to an early return. Still, it would have been a little nicer if it had been done in two commits.
- deleted 3y ago[deleted]
- CobrastanJorji 3y agoHere's a better view of it: https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae372dc88d1d1b1b5fd4783aec003da378c3e45 https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3... Basically it just adds a one line check near the top of a ShowTooltip() function for whether "doc->HasFocus(IgnoreErrors())", and, if not, returns early.
- em-bee 3y agoi always struggle with this. i usually end up with code changes first because i want to test code before committing, which means i can't commit a whitespace change before i know the code change works. and every time i think about the problem i stumble over python where the two can't be separated. i believe in the end a better solution would be to mark whitespace changes in a different color. or even better mark each character that changed, not just the line. in other words: we want better diff tools
- chopin 3y agoGerrit is capable of showing only non-whitespace diffs.