Skip to content
Snippets Groups Projects

Fix old MR diffs

Merged Sean McGivern requested to merge fix-old-mr-diffs into master

What does this MR do?

Fix old MR diffs, when we can't figure out the correct diff refs. This is in two commits. The first doesn't preview them, and the second makes them look like this (note that the added diff can still be highlighted!):

image

Are there points in the code the reviewer needs to double check?

  1. Should new_file? || deleted_file? || content_changed? be moved to a method? What should we call it?
  2. I didn't actually do https://gitlab.com/gitlab-org/gitlab-ce/issues/36516#note_38068227, but just redefined highlighted_diff_lines instead. This seems more natural to me, but maybe I'm missing something.

Why was this MR needed?

I broke fallback_diff_refs :face_palm:

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/36516.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Author Contributor

    To test this, I did:

    diff --git a/lib/gitlab/diff/file.rb b/lib/gitlab/diff/file.rb
    index f061753f4e..64cab6b0a8 100644
    --- a/lib/gitlab/diff/file.rb
    +++ b/lib/gitlab/diff/file.rb
    @@ -98,6 +98,7 @@ module Gitlab
    
           def old_blob
             return @old_blob if defined?(@old_blob)
    +        return @old_blob = new_blob if new_blob
    
             sha = old_content_sha
             return @old_blob = nil unless sha
    diff --git a/lib/gitlab/diff/file_collection/merge_request_diff.rb b/lib/gitlab/diff/file_collection/merge_request_diff.rb
    index fcda1fe223..21ca90dd69 100644
    --- a/lib/gitlab/diff/file_collection/merge_request_diff.rb
    +++ b/lib/gitlab/diff/file_collection/merge_request_diff.rb
    @@ -30,9 +30,9 @@ module Gitlab
             end
    
             def highlight_diff_file_from_cache!(diff_file, cache_diff_lines)
    -          diff_file.highlighted_diff_lines = cache_diff_lines.map do |line|
    -            Gitlab::Diff::Line.init_from_hash(line)
    -          end
    +          # diff_file.highlighted_diff_lines = cache_diff_lines.map do |line|
    +          #   Gitlab::Diff::Line.init_from_hash(line)
    +          # end
             end
    
             #
  • Sean McGivern restored source branch fix-old-mr-diffs

    restored source branch fix-old-mr-diffs

    1. I didn't actually do https://gitlab.com/gitlab-org/gitlab-ce/issues/36516#note_38068227, but just redefined highlighted_diff_lines instead. This seems more natural to me, but maybe I'm missing something.

    @smcgivern It think we should be able to use Diff#content_changed? regardless of whether there are blobs or not. Right now, the result is clearly wrong.

  • Douwe Maan
  • Douwe Maan
  • assigned to @smcgivern

  • Sean McGivern resolved all discussions

    resolved all discussions

  • Author Contributor

    @DouweM thanks, those reasons make sense. I've updated this now to just touch #content_changed? :thumbsup:

  • assigned to @DouweM

  • Sean McGivern added 1 commit

    added 1 commit

    • 6d372d9d - Show un-highlighted diffs when blobs are the same

    Compare with previous version

  • Douwe Maan
  • Douwe Maan
  • assigned to @smcgivern

  • assigned to @DouweM

  • Sean McGivern added 1 commit

    added 1 commit

    • 3d7bce91 - Show un-highlighted diffs when blobs are the same

    Compare with previous version

  • assigned to @smcgivern

  • Sean McGivern resolved all discussions

    resolved all discussions

  • Sean McGivern added 1 commit

    added 1 commit

    • e8525e10 - Show un-highlighted diffs when blobs are the same

    Compare with previous version

  • Author Contributor

    @DouweM thanks, updated to that - I agree that's clearer on the cause :thumbsup:

  • assigned to @DouweM

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading