NXD Teach GitLab about patches
Teach GitLab not only to merge changes from a merge-request, but also to
apply patches posted to merge-request in a way like `git am` would do -
without merge commit and directly on top of current branch. Which way to
go is selected by user in web UI, and apply patches is the first option.
There are 3 cases:
- only 1 commit is present in MR -> the only available option is to
apply that single commit as one patch without a merge
( There is no need for merge commit in this case at all: information
about user who applied the patch goes to "Committer" field in resultant
commit. Avoiding 1 merge per 1 patch results in cleaner history )
It is also possible to review patch description directly in web UI,
before doing the actual application, and correct / amend it as needed.
- several commits are present in MR:
* it is possible to apply the patches directly on top of current
branch. Again information about who applied what goes to "Committer"
field.
* it is possible to merge MR changes with making a merge commit.
This variant is useful, when patches from a MR do several logical
steps to reach one goal, and MR description contain cover letter for
whole patch series.
in this case original commits stay untouched and resulting merge
will contain MR author as author, user who accepted MR as committer,
and cover letter as merge commit message.
NOTE we avoid useless "Merge branch X into Y" in merge message, and
just put MR title into merge subject and MR description into merge
description.
This way it is more logical with more important information in
merge subject and thus e.g. more handy to oversee what a merge brings,
just by it subject, e.g. via looking at updates via
gitk --first-parent ...
or via web.
NOTE for pre-generated references to merge-request we now use full MR
URL, instead of !<MR-n>. Full URLs work everywhere, not only on
original site where MR was created, or even only in original repo
and not its fork on the same site.
| ... | @@ -415,13 +415,14 @@ class MergeRequest < ActiveRecord::Base | ... | @@ -415,13 +415,14 @@ class MergeRequest < ActiveRecord::Base |
| end | end | ||
| def merge_commit_message | def merge_commit_message | ||
| message = "Merge branch '#{source_branch}' into '#{target_branch}'" | #message = "Merge branch '#{source_branch}' into '#{target_branch}'" | ||
| message << "\n\n" | #message << "\n\n" | ||
| message = "" | |||
| message << title.to_s | message << title.to_s | ||
|
|||
| message << "\n\n" | message << "\n\n" | ||
| message << description.to_s | message << description.to_s | ||
| message << "\n\n" | message << "\n\n" if !description.to_s.empty? | ||
| message << "See merge request !#{iid}" | message << "/reviewed-on #{Gitlab::UrlBuilder.new(:merge_request).build(id)}" | ||
| message | message | ||
| end | end | ||
| ... | ... | ||
-
mentioned in commit slapos@138cfdb7
-
OwnerIn my opinion, this change is too big. I prefer either 1) make efforts to be accepted in upstream or 2) accept existing gitlab behaviour as it is. Maintaining such a big change is not so easy. (Do we have automated CI test for our patched branch ?)
-
Owner
This won't be accepted by upstream gitlab CE because it overlaps with GitLab EE (Enterprise Edition, proprietary licence) functionality (accept an MR with rebase).
We just have to carry it with us, since several people in Nexedi really cares about having good history. In my view this is not a big patch. (we do not have automated CI for our gitlab-ce branch, until now I was doing all the testing manually).
-
mentioned in merge request wendelin.core!14 (closed)
