Topic on Talk:GitLab consultation

I prefer the Gerrit workflow, where I can clone a repository, create changes & commit them and then push the change for review. I don't even have to create a branch! It is a really effective workflow for users who create patches against multiple repositories without being very involved in the development of that repository. A Github workflow (and from what I understand a GitLab workflow too) requires the user to fork the repository, create a branch and then a merge/pull request in the UI. If they (like I am prone to) forgot to fork first, they'll have to fork first, adjust the origin of their local repository and then go through with the other steps. This seems more work than with Gerrit currently.

It especially impacts users who do a lot of maintenance work on extensions and skins. I'd rather not have to maintain dozens upon dozens of forks just because I'm trying to deprecate a feature (for which all production usages have to be removed first, across the dozen of repositories used by WMF's MediaWiki).

GitLab also allows a workflow which does not require to first fork a repo before creating a branch. That require permissions though (e.g. being in a developer group). See e.g. https://wiki.gnome.org/GitLab#GitLab_workflow_for_code_contribution

If existing developers (perhaps trusted-contributors) are granted such permissions (with master protected) then that would make things easier, especially if, like mentioned creating a branch from the CLI is an option. It seems a bit wasteful to have multiple branches littering the repository, as it makes the distinction between feature branch/merge request branch and canonical branches (e.g release branches, collaboration feature branches) less distinct than it is now.

I concur with @Mainframe98 here that I prefer Gerrit's workflow. I've used gitlab in the past to contribute patches to other projects and I found the UI difficult at first and still kind of find it difficult.

I must admit I do like that gitlab includes a user interface to actually browse the code but I dislike it's workflow. I like Gerrit's workflow because you just create one commit rather than a merge commit with a ton of different commits because you decided to edit each file using the web ui. Gerrit creates one commit whilst using the webui, so your not like creating lots of commit.

I also like the fact that gerrit shows all recent commits regardless of projects as the main page (doesn't look possible in gitlab?). This allows really anyone to go to status:open and either provide input or merge without needing to know a project to look at.

Users get their own dashboard with Gerrit (I don't think this is possible with gitlab).

Gerrit also provides the command you need to use to amend you commit (if you want to do it locally) or want to test it out. It's also easy to create a change (e.g git push HEAD:refs/for/<branch>).

You also don't have to fork in order to contribute granted when you use the inline editor it forks automatically for you. But the disadvantage is you have a duplicate repo, the advantage is the user can do what ever they want with the repo. So like for example for MediaWiki forking that more than 1 times would use a lot of storage (please do tell me if I got this wrong).

Gerrit makes the life of the reviewer and owner easier by creating a simple user interface. Being able to comment, being able to contribute easily through the interface and also being able to find comments that you found you needed to address but missed it.

Wikimedia has had a great relationship with gerrit upstream. I'm sure if we engage we could get the features/ui changes done that our users request. Gerrit is very extensible via plugins and when it's not, upstream are quite accommodating into adding the extension/plugin points if you give a valid usecase. My work with the Gerrit Frontend Team has been quite good, they are willing to accept any requests as long as it has a usecase (though they've rejected some stuff).

@Paladox Could you elaborate the actual problem with "creating lots of commits"? I'm asking because you can squash them into a single commit when merging.

Forking: As I wrote in my previous comment in this thread there are workflows which do not require forking.

Showing all recent commits regardless of projects: GitLab offers that across projects too, within a group. See for example https://gitlab.gnome.org/groups/GNOME/-/merge_requests?state=opened.

Dashboard: Which specific functionality do you use and expect from your "own dashboard"? It's hard to discuss if we don't know which problem a dashboards solves for you.

(Furthermore, I personally disagree that Gerrit "creates a simple user interface". Random example: Try to create a code change within the web interface, without reading the docs. Hint: It is possible.)

A commit is meant to be atomic in nature, most code reviewers prefer multiple commits with each commit dealing with one thing only - in fact, the Gerrit way of having patchsets with one commit doing a lot of things is in the minority and only works because of the patchset-based workflow. Furthermore, Andre's point in the brackets is what's most important, (almost?) every newcomer to Gerrit has found it opaque in nature and contrarian to the pull-request-based workflows that most new contributors are used to.

I strongly concur with@Paladox. Squash merge is not useful if you have multiple atomic commits that depend on each other, e.g., two small refactoring commits and one commit that does the behavior change. If there are any changes needed than you need to either 1. Create follow-up commits that survive the merge and lead to a very messy and useless git history or 2. Create follow-up commits and squash them all on merge leading to a single huge commit that does a ton of things or 3. Rewrite git history in your merge branch for which GitLab has absolutely crappy UI support. I'll might create an extra section for just that.

The dashboard in Gerrit shows me the status of: my WIP patches, my outgoing patches await review by peers, my incoming patches from peers awaiting my review. I use this quite a lot. Can GitLab do that?

As a newcomer you have a bit of a learning curve for the first month or two. That's it. Afterward you get enjoy the benefits of a much better code review experience for years. You also get to work with a git history that is actually meaningful and usable. I think that's worth it.

Squash merge is not useful if you have multiple atomic commits that depend on each other, e.g., two small refactoring commits and one commit that does the behavior change. If there are any changes needed than you need to either 1. Create follow-up commits that survive the merge and lead to a very messy and useless git history or 2. Create follow-up commits and squash them all on merge leading to a single huge commit that does a ton of things or 3. Rewrite git history in your merge branch for which GitLab has absolutely crappy UI support. I'll might create an extra section for just that.

In the commit history for the change you suggest (2 refactoring commits, 1 behavior change commit) the git history created by GitLab (if you choose to merge rather than squash) is more semantically rich than the information in the git history created by Gerrit.

In Gerrit the fact that the behavioral change was the onus for the refactoring is lost and there's no way to represent it in the git history since changes are all separate patchesets. Either you use the default merge strategy (merge-if-necessary ­which is what we use for mediawiki/core) which may or may not (depending on the state of master vs the state of these 3 patchset) create 3 separate merge commits for each of these 3 changes OR (alternatively) add these 3 commits in order in history. There's no information in git history indicating these 3 changes were developed together, that information only exists in the Gerrit UI (it's likely findable also on the individual refs/changes/).

I think rewriting git history is only a bad thing for a shared branch (like a release branch or a mainline branch) I don't think rewriting git history is a bad thing for merge requests. In the GitLab UI you can compare revisions after a --force push in a merge request, just like you can in gerrit when you git commit --amend and push to the refs/for/x special ref.

Re Dashboards:

Apart from my still open question which specific functionality you use and expect from your "own dashboard", in my understanding it is only possible to filter across repos via a label (like /dashboard/merge_requests?state=opened&label_name[]=LABELNAME) or within a group, but not on a custom subset of repos. The term "dashboard" in GitLab terminology seems to be about metrics.