Add option to ignore line endings and/or whitespace in a diff (BB-3879)

Issue #3812 duplicate
created an issue

I just submitted a smallish change. The website shows it as a humongous change because it considers every line as edited.

Presumably this must be due to line endings in some way.

I propose that the website diff ignores differing line endings and just normalises them. Otherwise the diff is just not useful.

Here is an example.

Comments (105)

  1. Health Monitoring Systems

    Not to split hairs, but to me this issue is not a duplicate of #6024. That issue is for side-by-side view (which is decent enough imho), whereas this issue is for the default diff view (where I'd like to have an option to ignore whitespaces and linebreaks with a ?w=1 or something like that appended in URL like what GitHub does).

  2. Howard Jess

    Not a dup. The side-by-side display is not fully equivalent to the standard diff. Why would you want to support the w=1 flag in only one mode? That would seem to be more difficult than allowing it in either mode.

  3. Mark Ericson

    +1 I battle this constantly. Isn't this just a matter of SourceTree exposing config that gets passed through to git diff which already supports line-ending and/or whitespace options?

    Work-around is to use an external Merge tool

  4. Sean McCarthy

    Everyone who cares about this- vote for it and get everyone in your development team to do the same. At the moment this issue ranks 15th by votes.

    Also, there's a similar issue raised about ignoring whitespace in side by side diffs: #6024

    If we vote for that too, maybe the fix will address both issues.

  5. Michael Bean

    However, perhaps we could all make another and merge the two, mark the smaller ones as duplicates. We could then just use the vote button. Perhaps BB personnel are ignoring these because they don't want to read all the comments....

  6. Ralph Callaway

    Sigh, two years, and no love. We've got a great "optimized" ui that gives me tons of space of a readme I never used, hides all the stuff I did use, and I still can't do a code review without having to pick through a ton of white space noise.

    Bitbucket, step it up, Atlassian kicks ass, this is really out of character.

  7. Brian Naberhuis

    I find it terribly amusing that SourceTree (another AtLassian product) has the ability to ignore whitespace in diffs, but that the BitBucket viewers do not. If I could only service pull requests from SourceTree, this would not be an issue at all.

    As is, unless the submitter turns off a lot of helpful editor features, you end up with tons of whitespace fixes in legacy codebases, and they make it utterly impossible to notice changes that are important.

  8. Andrew Dunai

    You, bitbucket devs, are dicks. It's already TWO FUCKING YEARS people begging you to add this feature. Two years to add this shit? Really? Fuck you, I'm moving somewhere else.

  9. Jens Schumacher staff

    Andrew, we realise that having to wait 2 years for a seemingly small feature being implemented can be frustrating. However, your comment is completely inappropriate and disrespectful to the developers who provide you with a free service.

  10. Per

    @Jens Schumacher, agree that the comment goes too far. However, you tend to forget that not everyone is using Bitbucket as a free service.

    We have been using Bitbucket's paid service for years, but have recently (since a few months) started to move over to one of your competitors. They provide this feature (and other nice things as well). So, it's not just a matter of "this is a free service, take it like it is"; you do in fact have a bunch of paying customers that do not get the attention they deserve - 2 years of neglecting is a long, long time. That is a real problem IMHO.

  11. Ben Madore

    @Per @Jens Schumacher - agreed on both counts. @Jens Schumacher you really have to understand that a non-trivial amount of us out here are paying for this product - to treat everyone complaining as if we some sort of freeloaders, is itself a bit offensive. At the very least we should have a reasonable expectation that Atlassian would at least provide occasional feedback on tickets like these, it is INCREDIBLY frustrating to have a service provider completely ignore their customers in the manner that Atlassian does. I don't expect that every feature request must implemented, or even that a precise timeline be given for ones that are... but I think customers should have a reasonable expectation that Atlassian would monitor these issues, and would provide occasional feedback such that it doesn't feel like we are all just shouting into the ether, and going completely ignored. As a customer, feeling intentionally, almost antagonistically ignored, is not the way I would like to feel about a company. I very often feel that way about Atlassian, on the whole your products are good, but your customer service leaves very, very much to be desired. A little attention (i.e. reading and updating highly voted, longstanding feature requests) goes a very long way toward making customers a bit more satisfied to be forking over money month after month, year after year. I don't think it is too much to be asked.

  12. Ralph Callaway

    @Jens Schumacher ditto, we pay for bitbucket, and while that comment was over the line, you really should be taking it as a warning sign that you or product management or whoever is making the prioritization decisions really shit the bed on this one, the new UI is well, new, and beyond that, not a major difference to my day to day operation, not saying I don't love freshening up, but when the most basic, basic, basic feature of all git clients isn't available, people get VERY angry, particularly when they ARE paying for it.

    Given the amount of ill will you guys have built up I think this warrants more than a cursory, we're working on it, but we can't promise, i think a LOT of people on this thread would appreciate an apology from you guys, and an immediate cessation to the woe is me bullshit

  13. Boyd Ludlow

    My question is "Do Atlassian eat their own dog food?" If the Atlassian developers are using BitBucket surely they are encountering this issue themselves. If so do they just not find it to be a big deal? If not what practice are they following on the client to avoid false positive hits by the server differencing tool caused by whitespace characters?

  14. Matthew Nichols

    I agree also that Andrews comment is a bit over the top (why get angry when you can just go elsewhere). And I also pay for two seperate Bitbucket accounts (plus other Atlasian products) and just recommended a customer purchase a paid Bitbucket account. But I find this a very frustrating issue as it increases the amount of time that code reviews take many times. This is the sort thing that has Github beating you feature-wise at every turn. I like your pricing model and I prefer Mercurial so I am here, but you guys make this a hard decision to keep making. Please make it easier to continue paying for and recommending your product.

  15. Jens Schumacher staff

    Let me be clear that my reply was specifically addressing Andrew's comment. I don't believe we should tolerate profanity from any member in the community.

    We encourage and display customer comments and votes openly in our issue tracking system. I believe this is fairly unique for a company with tens of thousands of customers and millions of users. It is something I've personally always loved about Atlassian. But to be honest, it has become increasingly difficult to maintain this openness and manage expectations at the same time.

    In Bitbucket alone we have 1701 open issues. I am sure you would agree that providing an update to every single one of them on a frequent basis is simply not feasible, which is not to say we can't do better. I'll get to that in a bit. Although we might not comment on all issues, we do discuss the top voted features frequently and closely monitor new comments. Of course these are internal discussions and not publicly visible. No wonder it looks like we are ignoring our users. This is exactly why it has become difficult to maintain our openness. We haven't found a great way to communicate our internal discussions and thought processes without introducing a massive amount of overhead.

    How can we do better? We certainly can not provide updates on all issues, but we should provide updates on the most popular ones. We have started doing this for other products and are planning to do the same for Bitbucket. Every 3-6 months we will provide an update on the top 25 issues. We will let you know whether the feature has been scheduled or is being considered within the next 12 months. But we will not be able to give you a specific time frame. We have been wrong in the past and we will be wrong in the future, but we will do the best we can.

    Lastly, let me address this specific issue. A number of teams at Atlassian use Bitbucket and this issue hasn't been a big deal for us internally. If whitespace has been changed, it certainly drastically limits the ability to review the changes effectively. But whitespace changes are not that common, or at least that's what we've thought. Looking at your comments, this assumption is wrong in some cases. The good news is that we have been discussing this issue, acknowledged it's importance and scheduled it on our roadmap as one of the next items to be delivered. We know it's been 2+ years for what seems (and hopefully will be) a small feature and we thank you for your patience.

    Cheers, Jens

  16. Michael Bean

    @Jens Schumacher : Although you cannot provide a personalized update to each issue, it would be nice if you provided the ability for us to see where it is in the pipeline. Or perhaps see that the rank of the ticket is increasing over time. If other features really do have more votes, I can see how something can be ignored. Maybe we should all request and vote on an issue for that? What does everyone think?

    Also, perhaps some of your 1700 issues are duplicates (feasible when there are that many). This could easily make some tickets have lower rank than they otherwise should. You might be able to employ some ML kNN on your text to determine where tickets are likely to be duplicates (or locate ones that should be merged). Sentiment analysis (a text mining task) might help you discover tickets where users are particularly fired up about things. Enjoy spinning off tickets from these ideas; They aren't something I'll request since I can't see them directly helping my tasks (although they'd probably help you rank tasks). This ticket itself has been marked as a duplicate, and I think there are 2-3 others like it that were all hinting at the same thing. Merging makes sense in some cases (marking some as duplicates as a result). That, in itself, shows that you are looking at things, but some might argue that it just indicates that you know you probably have duplicates and are doing (perhaps one-off) clean up.

  17. Ralph Callaway

    @Jens Schumacher thanks for the detailed reply, plus 1,000,000 for looking at committing to giving updates on the top 25 issues, that only would allay a huge amount of the frustration in this group. Having worked in support 1.7k issues sounds pretty darn low to what I've worked with, and you'll need to adopt a strategy of disregarding the small stuff in favor of letting the community surface. When you look at it that way, the number of issues with more than 100 votes starts to seem pretty manageable.

    You might consider taking a look at how salesforce manages their ideas stuff, they have a status "Under Consideration" that can be used to flag stuff that they're looking at. Everyone knows you can't commit to timelines. We just want to know what's going on, and given you're only doing public updates infrequently, exposing it's status internally will do alot to allay the community.

    Also, if you merge this with it's duplicate, this is literally the top issue. So you'll forgive us if we're impatient to see results.

  18. Ralph Callaway

    @Jens Schumacher and regarding profanity i'm with you, it's just not productive. But this isn't a typical flame war. that f bomb is what literally every person on this post has wanted to write for months, but out of common decency has held back. And frankly that profanity has done want months of frustrated postings from other users on this thread has not. Finally gotten your attention.

  19. Ben Madore

    @Ralph Callaway sadly, that's true, despite it's lack of respectfulness, the profane comment is really what finally got us a response (and, I'm pretty sure I've lost it to that extent on other open tickets). Unfortunately Atlassian's behavior to this point simply incentivizes their customers to get "cursing mad" to receive any sort of response. I am hopeful though that they will follow through on this new approach of being respectful and responsive (within reason) to their customers' desires.

    @Jens Schumacher i'm excited to hear you guys are going to start being a bit more attentive to your customers and more public with your plans, I don't necessarily buy that it takes a significant amount of work to be a bit more open about user requests, I think it takes a bit of organizational shift, but if you think of this like managing any other agile backlog, managing occasional updates to the top X feature requests is not a large task. Heck, our team of 3 solution analysts regularly updates on the order of 100 backlog items a month with updated information. Either way, the excuse of "having passionate customers is too hard" is not an acceptable position to take an *-as-a-service business. I (hope at least) that everyone is on the same page that we don't expect precise estimates. I know you were just responding to the 'dogfooding' comment, when you mentioned this wasn't an issue for you guys internally, but I hope going forward your team focuses less on your own needs for features - and more on the ones your clients are specifically telling you about. For instance, my team has developers using multiple IDEs (sublime, eclipse, intellij, emacs, vim) and despite having configured code formatters, they aren't perfect, and almost every single merge has some sort of whitespace issue. Take that for what it's worth. Honestly though, thanks for stepping up and taking steps toward making your customers feel more respected.

  20. Zachary Davis

    I would just like to squash the misconception that the profanity-laden comment in question is what got our attention or led us to respond here. It's simply not true.

    We've been trying to figure out where this fits on our roadmap since well before that comment was made, and we took into account the votes and the overall tenor of the recent comments ("This is a critical feature" -- especially on the related issue) not the interspersed threats or vitriol (while a clear indication of frustration, those things are often demotivating as a developer).

    As for the timing of our response, the simple truth is that we recently did some major roadmap planning to decide what we'd like to tackle in the coming quarters, and we felt that responding here was the first step in being more communicative (as Jens laid out above).

  21. Ben Madore

    @Zachary Davis Thanks Zach, that clarification is definitely helpful, whether or not it was the case, to a casual observer based on no information other than timing of responses it could be perhaps inferred that a particularly rude/heated comment is what finally lead to a response. I hope your clarification helps keep future people from deciding the best way to get a response is via name calling

  22. Brill Pappin

    Jens, it's a very common happening, even with teams that are all using the same development tools and settings. Its way more of a problem with distributed teams that are not using the same tools and/or settings.

    The biggest issue is that formating a file causes a lot of whitespace changes that are nkt actual code changes. Even adding a space adds yet another one. If you have some code to review (it doesn't even have to be that much), picking through all the whitespace changes (that don't mean anything to the code), makes the tool unusable.

  23. Josh Passenger

    OMG confirmed! I do think in hind sight that fixing this might have been cheaper for Atlassian than responding to the hundreds of negative posts, and yet there is no UI option for this yet so its not fixed as most users will still be frustrated by this...

  24. Log in to comment