upstream applied #64
Merged
upstream applied #64
Conversation
This file contains 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
Using `progress.finish_with_message` causes the progress meter to be finished, and replaced with the given message. However, the progress meter doesn't appear at all in non-interactive contexts. We want the final, non-progress message to still appear in this output (such as in tests). Use `println!` in those cases rather than `progress.finish_with_message`.
In the stacked-diffs workflow, the user may have a stack of commits locally and submit only the bottom commits for review at first. Those commits may be accepted and merged into the main branch. Afterwards, the user wants to rebase their local work onto the main branch, such that the commits which have already been applied upstream disappear. Base Git accomplishes this via two mechanisms: - The patch ID mechanism. A "patch ID" is a checksum of the patch's textual content. Git computes the patch IDs for all commits which have been applied to the main branch in the meantime. If any of the local commits have a patch ID which is the same as any of the upstream commits, then the commit is skipped. - Removing empty commits. There are some cases where the patch ID is not enough to identify changes which have been applied upstream. The upstream main branch may have combined multiple commits into one commit, which means that the patches have been applied, but the exact commits are no longer there. If, after applying a given commit, the commit's contents are found to be empty (which is to say that it introduced no new changes compared to upstream), then the commit is skipped. This commit implements support for both mechanisms in `git move`, both for the in-memory and on-disk rebase engines. Additionally, to support the stacked-diffs workflow, the behavior for abandoned branches is different in `git move` than in `git rebase`. In Git, if a given commit has been skipped, then its corresponding branch will be attached to its closest parent which hasn't been skipped. Oftentimes, this means that the branch gets applied to the same commit which the main branch points to. In `git move`, we instead delete branches which point to commits which have been skipped, assuming that they correspond to closed pull requests.
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.
No description provided.