Absorb gitlab_git

As briefly discussed in the backend call, I propose to extract our https://gitlab.com/gitlab-org/gitlab_git gem into this repo to improve code findability and reuse, and to make it less cumbersome to make changes that touch both codebases. Currently this requires cloning gitlab_git separately, pointing the gitlab-rails Gemfile to the path, reloading the whole server every time you make a change, and finally submitting separate MRs to both projects, where the gitlab-ce one references the user's own gitlab_git fork and branch, so that the gitlab-ce build can succeed. After that, the gitlab_git one needs to be merged first, a new version of the gitlab_git gem needs to be released, the gitlab-ce MR needs to be updated with the new gitlab_git version, and then the gitlab-ce MR can be merged. That could just have been one simple MR.

In the backend call, I got explicit +1's from @smcgivern, @rspeicher, @patricio, @rymai, @vsizov, @zj and @adamniedzielski, so I guess we're doing this :)

/cc @dzaporozhets @jacobvosmaer-gitlab @stanhu @yorickpeterse

Mentioned in issue #24265 (moved)

from me. Another advantage is that we can now also use the git path specified in the GitLab configuration for all calls within gitlab_git. Right now, GitLab uses the configured one whereas gitlab_git uses the system one.

@razer6 Yes, good idea!

Explicit +1 from me.

I am not against this because it's certainly helping development and deployment for us. However I heard some people are using gitlab_git and I feel bad for them :P I guess we could still backport to the gem once in a while so there's not much difference when using the gem directly though!

I guess we could still backport to the gem once in a while so there's not much difference when using the gem directly though!

I don't think this is worth the effort. The Gem is called gitlab_git for a rather specific reason: it's specific to GitLab. Current users can continue using the Gem, we just won't be adding anything to it.

We are already changing gitlab_git every month in backward incompatible ways, and haven't gotten any backlash from potential non-GitLab users. I have a hunch that we are the only project that actively uses gitlab_git—any other project is better off using rugged directly.

Added ~307491 label

Mentioned in merge request !7536 (closed)

Mentioned in merge request gitlab_git!134 (merged)

Reassigned to @DouweM

Mentioned in issue #20617 (moved)

Added Deliverable and removed ~307491 ~480950 backstage technical debt labels

Added ~480950 backstage technical debt labels

I am also OK with this. Also see https://gitlab.com/gitlab-org/gitlab-shell/issues/44 for a proposal to move parts of gitlab-shell into this repo.

mentioned in issue #25871 (closed)

changed milestone to %8.16

assigned to @rspeicher

mentioned in merge request !8447 (merged)

closed via merge request !8447 (merged)

mentioned in commit tnir/gitlab-ce@efb8da89

mentioned in merge request gitlab_git!134 (merged)

mentioned in merge request gitlab_git!135 (closed)

mentioned in merge request gitlab_git!133 (closed)

mentioned in merge request gitlab_git!105 (closed)

mentioned in merge request gitlab_git!94 (closed)

mentioned in merge request gitlab_git!58 (closed)

mentioned in merge request gitlab_git!13 (closed)

mentioned in merge request !14785