When concerned about evil actors sneaking changes into a repository one normally thinks of subtle one-line changes. Gitlab further helps the adversary by collapsing too big changes too subtly.
Currently GL in diff views collapses big files without any very visible clue to the reviewer that he might miss some reviewing there.
Proposal
Always include the first lines of every file and if it's too long, make it fade out to the bottom with an expand button.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
@Giszmo what if the file is (say) a minified JavaScript file, which is all on one line? We don't show the file for performance reasons, but showing the first line is showing the file. I think we can talk about making it clearer that a file is collapsed, but I don't think this is the right solution
I agree with @smcgivern. The minified JS file is a good example where showing the first couple lines doesn't make sense or really help. With the string of text This diff is collapsed. Click to expand it., the state feels clear to me. But is the problem more when you are scrolling through a lot of diffs, it is easy to miss the collapsed ones?
There have been some issues recently with regards to collapsed diffs when an MR is large. This has caused some people to miss some files during the review.Is there any way to make the files that have been collapsed more visible or to even have the option to always expand them?
I would be fine with simply giving it more visibility. Make it a blinking gif alert thing or something but not some pale white extra line that can all too easily be missed.
Alternatively make it a dummy diff.
- Click here to expand+ You are looking at a dummy diff!!! Click here to see the actual diff!!
When I'm reviewing code, my brain totally focuses on the red- and green parts and tries to quickly detect if it's just the rename-thing that went on for pages or if it's some new logic etc. I would pay attention to anything that looks like code, less to anything that looks like a comment and even less to what goes on outside of the red and green marked lines. Using the same red or green would definitely catch my attention.
@Bessonov1 so if you edit the end of a 20 MB text file, you'll only see a small part that's unchanged? Or, if you mean the diff, you'll see an incomplete diff? I'm not sure how that would help, but if you could explain what the files you're hitting these limits with are, that would help
@smcgivern oh, I'm sorry, it was in my mind, but you can't look into With no collapsed I meant not entirely collapsed, but as you said, incomplete diff. I try with images :)
Not good (current):
Good (this proposal) :
For me it's enough to show just first bytes of changes.
I think it is barely an improvement if the "collapsed" notification remains as innocent as is. A reviewer could fall for thinking he's looking at an exhaustive list of changes to the file this way. Also it does not address the issue with files that consist of 1MB without a line break.
Which brings me to a different proposal: How about showing too big diffs more like binary diffs?
First of all, thank you for raising an issue to help improve the GitLab product. This issue was labelled as a ~"feature proposal" in the past. In order to maintain order in the issue tracker, we are starting to close off old, unpopular feature proposals that have not gained many votes since opening.
This issue will be marked for closure, as it meets the following criteria:
Created over 1 year ago
Labelled as a ~"feature proposal"
Unscheduled (not associated with a milestone)
Less than 10 upvotes
Thanks for your help and please raise any new feature proposals as a new issue.