28428942f4
In normal git usage, cherry-picking a commit that has already been applied and doesn't do anything or cherry-picking an empty commit causes git to exit with an error to let the user decide what they want to do. However, this doesn't match the behavior of merges and rebases where non-empty commits that have already been applied are simply skipped (empty source commits are preserved). To fix this, add the --keep-redundant-commit option to `git cherry-pick` to make git always keep a commit when cherry-picking even when it is empty for either reason. Then, after the cherry-pick, check if the new commit is empty and if so back it out if the original commit _wasn't_ empty. This two step process is necessary because git doesn't have any options to simply skip cherry-pick commits that have already been applied to the tree. Removing commits that have already been applied is particularly important in a "deploy" pipeline triggered by a Gerrit "change-merged" event, since the scheduler will try to cherry-pick the change on top of the commit that just merged. Without this option, the cherry-pick will fail and the deploy pipeline will fail with a MERGE_CONFICT. Change-Id: I326ba49e2268197662d11fd79e46f3c020675f21
15 lines
590 B
YAML
15 lines
590 B
YAML
---
|
|
fixes:
|
|
- |
|
|
The `cherry-pick` merge mode will now silently skip commits that have
|
|
already been applied to the tree when cherry-picking, instead of failing
|
|
with an error.
|
|
|
|
The exception to this is if the source of the cherry-pick is an empty
|
|
commit, in which case it is always kept.
|
|
|
|
Skipping commits that have already been applied is important in a pipeline
|
|
triggered by the Gerrit `change-merged` event (like the `deploy` pipeline),
|
|
since the scheduler would previously try to cherry-pick the change on top
|
|
of the commit that just merged and fail.
|