Gitlab Integration

[mikeynap]

How open are you to receiving PRs for Gitlab integration? I want it so bad, I'm willing to do it :)

If you are open to it, do you have anything I should keep in mind or advice before digging in?

By the way, I love what you guys have made; it has made my transition from Phabricator back to git much easier! Thank you for the awesome project!

[PawelLipski]

Wowow 😯 sure! we're open to external contributions, received quite a lot of them, esp. in the last year.

Unfortunately, nobody on our team has much experience with GitLab... so your expertise will be much valued!

I'd follow the general approach taken by us in git machete github... in fact many parts of the code for github subcommand can be shared by gitlab subcommand as well. Not very much is GitHub specific (mostly git_machete/github.py).

By the way, I love what you guys have made; it has made my transition from Phabricator back to git much easier! Thank you for the awesome project!

Aww nice to hear 😊 out of curiosty, were migrating a specific project/organization from Phabricator, or were you yourself changing your tool of choice from Phabricator to git? 🤔

[mikeynap]

I used phabricator/mercurial at Facebook where I fell in love with stacks. My new job uses gitlab.

Yeah it looked pretty straight forward To swap out the backend for gitlab. I’ll get started on it over the next week!

[max-nicholson]

@mikeynap did you end up having a go at this?

I've taken a look, and it does look like a good chunk of the Github code could be re-usable, but it seems like a non-trivial refactor.

@PawelLipski is there any "core" functionality to replicate for Gitlab that could be standalone, or would all behaviour need replicating.

[PawelLipski]

I've taken a look, and it does look like a good chunk of the Github code could be re-usable, but it seems like a non-trivial refactor.

Yeah, I myself suspect that:

• GitHub-related code in client.py can, in principle, be generalized to work both with GitHub and GitLab. There'll still be almost surely some divergences for non-trivial cases, like git machete github restack-pr and support for enterprise domains.
• github.py is meant as a relatively low-level GitHub API client, and this would need to be reimplemented. Ofc the interface of GitHubClient class would need to be more or less retained, to facilitate reusing client.py code for both GitHub and GitLab.

Actually... what I would suggest, if you could guys just provide a sketch of github.py rewritten to handle GitLab API instead, then I can follow up with the neccessary changes to client.py, CLI, docs etc. 🤔

[PawelLipski]

...work started at https://github.com/VirtusLab/git-machete/pull/1189 😅

[max-nicholson]

👍 . Had started a couple of weeks back, and admittedly hadn't got far - https://github.com/VirtusLab/git-machete/compare/master...max-nicholson:git-machete:add-gitlab

Looks like you've already gone beyond what I'd already done.

Let me know how I can help with the PR

[max-nicholson]

The first thing that seemed quite different to Github (and wasn't sure how to reconcile) was the OrganizationAndRepository interface/config.

Gitlab instead has a concept of "Namespaces" and "Projects". A "Project" holds a "Repository" (1:1), but the API for PRs (known as MR in Gitlab) and other entities reference the "Project" rather than the "Repository".

https://docs.gitlab.com/ee/api/merge_requests.html#create-mr

A Namespace is a "/" separated string, which contains at least 1 group, and possibly up to 20 subgroups of nesting, then "/{name of project}" You can alternatively provide just a project ID (which is a globally unique integer).

so potentially we could support

machete.gitlab.namespace: "some/nested/namespace/path"
machete.gitlab.project: "my-project"

OR

machete.gitlab.projectId: 123456

but this is obviously very different to Github (both externally, and internal abstractions).

Alternatively the "Organization" and "Repository" config/class is kept, but the remote_url_patterns would need to support multiple subgroups for Gitlab e.g. https://gitlab.com/myorg/myorg-subgroup/myorg-some-initiative/project-name.git is a codebase I'm currently working on

[max-nicholson]

I've just pushed to my fork branch the remaining WIP changes I had - mostly around the Namespace / Project I mentioned above + starting on a generic API Client. Feel free to use any/none of it - but it's there incase anything is useful

[PawelLipski]

Nice! I'm gonna take a look, thanks

[PawelLipski]

Update: I've got git machete gitlab anno-prs (ofc all subcommands to be renamed to ...-mr(s)) to work. It's downhill from there :)

[PawelLipski]

Almost there... tests and shell completions missing, for the most part 😅

Btw guys @max-nicholson @mikeynap, do you think that git machete gitlab restack-mr (not to be confused with retarget-mr) makes sense, just as git machete github restack-pr? Pls check issue #1057 for rationale of restack-pr... but generally it combines retarget-pr and force-push, all wrapped into marking a PR as draft (to avoid notifying code owners) and then marking as ready again at the end.

[PawelLipski]

Almost ready... to be released as 3.25.0 within a couple hours 🎉