{{ message }}
Repository navigation
feat(dev-infra): merge script should link to original commit when cherry-picking with API strategy - #37889
Closed
devversion wants to merge 1 commit into
Closed
feat(dev-infra): merge script should link to original commit when cherry-picking with API strategy#37889devversion wants to merge 1 commit into
devversion wants to merge 1 commit into
Conversation
…rry-picking with API strategy The merge script uses `git cherry-pick` for both the API merge strategy and the autosquash strategy. It uses cherry-pick to push commits to different target branches (e.g. into the `10.0.x` branch). Those commits never point to the commits that landed in the primary Github branch though. For the autosquash strategy the pull request number is always included, so there is a way to go back to the source. On the other hand though, for commits cherry-picked in the API merge strategy, the pull request number might not always be included (due to Github's implementation of the rebase merge method). e.g. angular/components@27f5271 For those cases we'd want to link the cherry-picked commits to the original commits so that the corresponding PR is easier to track down. This is not needed for the autosquash strategy (as outlined before), but it would have been good for consistency. Unfortunately though this would rather complicate the strategy as the autosquash strategy cherry-picks directly from the PR head, so the SHAs that are used in the primary branch are not known.
alxhub
pushed a commit
that referenced
this pull request
Jul 7, 2020
…rry-picking with API strategy (#37889) The merge script uses `git cherry-pick` for both the API merge strategy and the autosquash strategy. It uses cherry-pick to push commits to different target branches (e.g. into the `10.0.x` branch). Those commits never point to the commits that landed in the primary Github branch though. For the autosquash strategy the pull request number is always included, so there is a way to go back to the source. On the other hand though, for commits cherry-picked in the API merge strategy, the pull request number might not always be included (due to Github's implementation of the rebase merge method). e.g. angular/components@27f5271 For those cases we'd want to link the cherry-picked commits to the original commits so that the corresponding PR is easier to track down. This is not needed for the autosquash strategy (as outlined before), but it would have been good for consistency. Unfortunately though this would rather complicate the strategy as the autosquash strategy cherry-picks directly from the PR head, so the SHAs that are used in the primary branch are not known. PR Close #37889
profanis
pushed a commit
to profanis/angular
that referenced
this pull request
Sep 5, 2020
…rry-picking with API strategy (angular#37889) The merge script uses `git cherry-pick` for both the API merge strategy and the autosquash strategy. It uses cherry-pick to push commits to different target branches (e.g. into the `10.0.x` branch). Those commits never point to the commits that landed in the primary Github branch though. For the autosquash strategy the pull request number is always included, so there is a way to go back to the source. On the other hand though, for commits cherry-picked in the API merge strategy, the pull request number might not always be included (due to Github's implementation of the rebase merge method). e.g. angular/components@27f5271 For those cases we'd want to link the cherry-picked commits to the original commits so that the corresponding PR is easier to track down. This is not needed for the autosquash strategy (as outlined before), but it would have been good for consistency. Unfortunately though this would rather complicate the strategy as the autosquash strategy cherry-picks directly from the PR head, so the SHAs that are used in the primary branch are not known. PR Close angular#37889
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

The merge script uses
git cherry-pickfor both the API merge strategyand the autosquash strategy. It uses cherry-pick to push commits to
different target branches (e.g. into the
10.0.xbranch).Those commits never point to the commits that landed in the primary
Github branch though. For the autosquash strategy the pull request number
is always included, so there is a way to go back to the source. On the other
hand though, for commits cherry-picked in the API merge strategy, the
pull request number might not always be included (due to Github's
implementation of the rebase merge method).
e.g. angular/components@27f5271
For those cases we'd want to link the cherry-picked commits to the
original commits so that the corresponding PR is easier to track
down. This is not needed for the autosquash strategy (as outlined
before), but it would have been good for consistency. Unfortunately
though this would rather complicate the strategy as the autosquash
strategy cherry-picks directly from the PR head, so the SHAs that
are used in the primary branch are not known.