... | ... | @@ -2,16 +2,16 @@ |
|
|
|
|
|
## Introduction
|
|
|
|
|
|
When a Merge Request is merged into *master*, it may need to be backported to maintenance branches. As each Merge Request consists of multiple commits, backporting it to another branch without squashing boils down to:
|
|
|
When a merge request is merged into *master*, it may need to be backported to maintenance branches. As each merge request consists of multiple commits, backporting it to another branch without squashing boils down to:
|
|
|
|
|
|
* cherry-picking the original commits comprising the Merge Request one-by-one on top of the target branch (i.e. the branch to which the Merge Request is being backported),
|
|
|
* creating a merge commit linking the previous HEAD of the target branch with the last cherry-picked commit, preferably retaining the commit log message from the original merge commit (e.g. to leave the Merge Request identifier intact for future reference).
|
|
|
* cherry-picking the original commits comprising the merge request one-by-one on top of the target branch (i.e. the branch to which the merge request is being backported),
|
|
|
* creating a merge commit linking the previous HEAD of the target branch with the last cherry-picked commit, preferably retaining the commit log message from the original merge commit (e.g. to leave the merge request identifier intact for future reference).
|
|
|
|
|
|
## `git-replay-merge` to the rescue
|
|
|
## `git-replay-merge.sh` to the rescue
|
|
|
|
|
|
### Overview
|
|
|
|
|
|
A script called `git-replay-merge` was written to make backporting Merge Requests more convenient by automating the process as much as possible.
|
|
|
A script called `git-replay-merge.sh` was written to make backporting merge requests more convenient by automating the process as much as possible.
|
|
|
|
|
|
### How it works
|
|
|
|
... | ... | @@ -25,19 +25,25 @@ The script can be thought of as a wrapper for `git cherry-pick` and `git merge` |
|
|
|
|
|
Summing up, given:
|
|
|
|
|
|
* the ID of the merge commit in the "original" branch (i.e. the branch the Merge Request was merged into),
|
|
|
* the ID of the merge commit in the "original" branch (i.e. the branch the merge request was merged into),
|
|
|
* the name of the git remote to ask about the target branch,
|
|
|
* the name of the target branch,
|
|
|
|
|
|
the script prepares a local branch with the relevant Merge Request "replayed" for pushing.
|
|
|
the script prepares a local branch with the relevant merge request "replayed" for pushing.
|
|
|
|
|
|
The script only prepares a branch for pushing; it is *not* pushed automatically.
|
|
|
|
|
|
If at any point in the process the user decides the script should not continue its work, `git replay-merge --abort` can be used to restore the working copy to the state it was in before `git replay-merge` was called.
|
|
|
If at any point in the process the user decides the script should not continue its work, `--abort` can be used to restore the working copy to the state it was in before the script was called.
|
|
|
|
|
|
### Installation
|
|
|
|
|
|
To use the script, [download it](https://gitlab.isc.org/isc-projects/bind9/snippets/2/raw?inline=false) to your development machine, saving it as `git-replay-merge` somewhere in your `$PATH`. Make sure it is executable. Running `git replay-merge` (without the first hyphen) should then reward you with a usage message:
|
|
|
To use the script:
|
|
|
|
|
|
* copy `util/git-replay-merge.sh` somewhere into your `$PATH`,
|
|
|
* rename the script to `git-replay-merge`,
|
|
|
* make sure the script is executable.
|
|
|
|
|
|
Running `git replay-merge` (without the first hyphen) should then reward you with a usage message:
|
|
|
|
|
|
```sh
|
|
|
$ git replay-merge
|
... | ... | @@ -250,3 +256,4 @@ To push the replay, use: |
|
|
```
|
|
|
|
|
|
That's it, the branch is all set for pushing.
|
|
|
|