As of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11584, any time new commits are pushed into an MR that directly touch lines that had diff discussions on them, these discussions are marked as outdated and get a system note with a link to the comparison between the two MR versions, and the exact line in that diff that represents that change.
This is useful for reviewers who may want to see how, exactly, their concerns ended up being addressed, before they mark the discussion as resolved, or to verify that a discussion that was resolved by the MR author was indeed addressed as expected.
However, the MR diffs page can be quite slow to load, especially when comparing two different versions (because the comparison isn't cached), and especially when the push involved a rebase or merged commit, which can result in changes being included in the diff that aren't actually relevant. (See also &340).
I would love it if the change diff was displayed in-line, as part of the system note, potentially behind a "Toggle diff" switch, as below:
It could just be a simple static diff with a few lines of context; if I want to see more context, or comment on the change, I can follow the "version X of the diff" link.
Given that's inherently a note being created for the change_position, I wonder if we could use the note_diff_files table in order to "cache" this raw diff. Otherwise we'll need N+1 Gitaly requests to provide this information
I think it might be interesting to not show the diff of the version that changed the line first, but show the diff between when the comment was made, and now (when viewing the MR).
That would show the reviewer what the result of the change is, instead of the first step in the process if there were multiple.
@jramsay The backend can expose the "change diff lines" on the API, but we'd need a new frontend component to actually display it. It doesn't sound like a ton of work, but I can't really speak for the frontend!
@mvanremmerden I think we have a lot of the UX patterns and components in place for this already. Would you be happy to help out with this in 12.2 while @pedroms is on leave?
This does look super helpful and interesting, great idea @DouweM! I would love to help out with this, but @phikai mentioned already that there might be a lot of UX work coming in %12.2, and we also still have quite some work for the UX OKR coming up, so it's tough to already make promises now.
How about we set up a call in the next days with both @phikai and @jareko to make sure we can take over the most important issues for @pedroms while also taking into account what is planned for our own groups?
Just as a thought, it's likely I have "less" planned for Knowledge, so there may be more room for @jareko. Maybe we sync (if needed) towards the end of next week (when I expect release planning to be done) and see what capacity looks like.
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. The current
gitlab-ce repository will become a read-only mirror, without any
proprietary code. All development is moved to the current
gitlab-ee repository, which we will rename to just gitlab in the
coming weeks. As part of this migration, issues will be moved to the
current gitlab-ee project.
If you have any questions about all of this, please ask them in our
dedicated FAQ issue.
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to
rename gitlab-ce to gitlab-foss to make the purpose of this FOSS
repository more clear
I created a merge requests for CE, and this got closed. What do I
need to do?
Everything in the ee/ directory is proprietary. Everything else is
free and open source software. If your merge request does not change
anything in the ee/ directory, the process of contributing changes
is the same as when using the gitlab-ce repository.
Will you accept merge requests on the gitlab-ce/gitlab-foss project
after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in
gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git
remotes to use this new URL. GitLab will take care of redirecting Git
operations so there is no hard deadline, but we recommend doing this
as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?