Handle a special case in reparenting when the new parent is in the middle of the branch's history #594
Conversation
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
…ddle of the branch's history This is a special case that can happen when the user has two branches that share some history. A scenario is: 1. A user creates a new branch from `main`. Add commits. Create a PR. 2. The user creates another branch off from the first branch, but with normal `git checkout -b` rather than `av branch`. Add commits. Create a PR. This new branch now contains all commits from the first branch. However, the parent of this new branch is still `main`. 3. The user tries to correct the parent-child relationship by reparenting the new branch onto the first branch. i.e. `av reparent --parent <first-branch>` on the new branch. When this happens, and when there are multiple commits on the first branch, Git tries to replay those commits when rebasing the second branch onto the first branch, which can lead to conflicts. There can be another way to create this situation, but after all, the point here is that we don't need to change the Git history when the new parent is already an ancestor of the current branch, and the new parent also contains the previous parent as an ancestor. Detect this case in sequencer and skip the rebase entirely. We still need to update the DB in order to track the new parent-child relationship, so we do that while skipping the Git rebase.
Contributor
Current Aviator status
This PR was merged using Aviator.
See the real-time status of this PR on the
Aviator webapp.
Use the Aviator Chrome Extension
to see the status of your PR within GitHub.
|
Contributor
✅ FlexReview StatusCommon Owner:
Review SLO: |
jainankit
approved these changes
Sep 22, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a special case that can happen when the user has two branches
that share some history. A scenario is:
main. Add commits. Create a PR.normal
git checkout -brather thanav branch. Add commits. Createa PR. This new branch now contains all commits from the first branch.
However, the parent of this new branch is still
main.reparenting the new branch onto the first branch. i.e.
av reparent --parent <first-branch>on the new branch.When this happens, and when there are multiple commits on the first
branch, Git tries to replay those commits when rebasing the second
branch onto the first branch, which can lead to conflicts.
There can be another way to create this situation, but after all, the
point here is that we don't need to change the Git history when the new
parent is already an ancestor of the current branch, and the new parent
also contains the previous parent as an ancestor. Detect this case in
sequencer and skip the rebase entirely. We still need to update the DB
in order to track the new parent-child relationship, so we do that while
skipping the Git rebase.