When passing start_branch on committing from the WebIDE, it's possible
that the branch has changed since editing started, which results in the
change being applied on top of the latest commit in the branch and
overwriting the new changes.

By passing the start_sha instead we can make sure that the change is
applied on top of the commit which the user started editing from.

Currently, MergeToRefService is specifically designed for
createing merge commits from source branch and target branch of
merge reqeusts. We extend this behavior to source branch and any
target ref paths.

Luke Duncalfe authored 5 years ago and Douwe Maan committed 5 years ago

The new two-step Gitaly `Rebase` RPC yields the rebase commit SHA to the
client before proceeding with the rebase.

This avoids an issue where the rebase commit SHA was returned when the
RPC had fully completed, and in some cases this would be after the Rails
`post_receive` worker services had already run. In these situations,
the merge request did not yet have its rebase_commit_sha attribute set
introducing the possibility for bugs (such as previous approvals being
reset).

https://gitlab.com/gitlab-org/gitlab-ee/issues/5966

This allows us to set the encoding of an IO passed without reading it
into memory.

This is useful if we want to stream files into Gitaly. Like we do when
uploading a new file to the repository.

This style change enforces `return if ...` instead of
`return nil if ...` to save maintainers a few minor review points

Patrick Bajao authored 6 years ago and Nick Thomas committed 6 years ago

When `force` is set to `true` and `start_branch` is set, the
branch will be ovewritten with the new commit based on the
`HEAD` of the `start_branch`.

This commit includes changes to update the `gitaly-proto` gem.

Adds the ground work for writing into
the merge ref refs/merge-requests/:iid/merge the
merge result between source and target branches of
a MR, without further side-effects such as
mailing, MR updates and target branch changes.

Enables frozen string for the following:

* lib/gitlab/fogbugz_import/**/*.rb
* lib/gitlab/gfm/**/*.rb
* lib/gitlab/git/**/*.rb
* lib/gitlab/gitaly_client/**/*.rb
* lib/gitlab/gitlab_import/**/*.rb
* lib/gitlab/google_code_import/**/*.rb
* lib/gitlab/gpg/**/*.rb
* lib/gitlab/grape_logging/**/*.rb
* lib/gitlab/graphql/**/*.rb
* lib/gitlab/graphs/**/*.rb
* lib/gitlab/hashed_storage/**/*.rb
* lib/gitlab/health_checks/**/*.rb

Partially address gitlab-org/gitlab-ce#47424.

This allows users to add patches as attachments to merge request
created via email.

When an email to create a merge request is sent, all the attachments
ending in `.patch` will be applied to the branch specified in the
subject of the email. If the branch did not exist, it will be created
from the HEAD of the repository.

When the patches could not be applied, the error message will be
replied to the user.

The patches can have a maximum combined size of 2MB for now.

This new endpoint allow users to update a submodule's reference.

The MR involves adding a new operation RPC operation in gitaly-proto
(see gitlab-org/gitaly-proto!233) and change Gitaly to use this
new version (see gitlab-org/gitaly!936).

See gitlab-org/gitlab-ce!20949

With this action the user can update the execute_filemode of a given file in the repository.

Closes gitaly#979

Closes gitaly#863

Closes gitaly#780

Closes gitaly#737

We also unify conversions from and to `Gitaly::User`s in the
`Gitlab::Git::User` class.

Closes gitaly#601

Closes gitaly#562