-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use merge-tree in patchsets instead of update-index #183
Labels
enhancement
New feature or request
Comments
jerry-skydio
added a commit
that referenced
this issue
Jul 3, 2024
Previously patchsets used a hacky invocation of update-index to overlay changed files from old tree to new tree. In addition to being slower than necessary, this has the downside of showing upstream changes in the diff, even those that were not changed in the given review upload. Using git merge-tree for this instead is cleaner, faster, and better. We do this by "cherry-picking" the old branch with git merge-tree, but providing -X ours as the strategy. This provides a tree that looks like the new base with the old changes applied. For cases where the old changes don't apply cleanly, the ours strategy prevents conflicts by taking the version in the old tree. Although this can be a bit confusing when looking at the file as a whole, it provides a succinct way to view a difference between the old version and new version. Topic: mergetreepatch Fixes: #183
jerry-skydio
added a commit
that referenced
this issue
Jul 3, 2024
Previously patchsets used a hacky invocation of update-index to overlay changed files from old tree to new tree. In addition to being slower than necessary, this has the downside of showing upstream changes in the diff, even those that were not changed in the given review upload. Using git merge-tree for this instead is cleaner, faster, and better. We do this by "cherry-picking" the old branch with git merge-tree, but providing -X ours as the strategy. This provides a tree that looks like the new base with the old changes applied. For cases where the old changes don't apply cleanly, the ours strategy prevents conflicts by taking the version in the old tree. Although this can be a bit confusing when looking at the file as a whole, it provides a succinct way to view a difference between the old version and new version. Topic: mergetreepatch Fixes: #183
jerry-skydio
added a commit
that referenced
this issue
Jul 3, 2024
Previously patchsets used a hacky invocation of update-index to overlay changed files from old tree to new tree. In addition to being slower than necessary, this has the downside of showing upstream changes in the diff, even those that were not changed in the given review upload. Using git merge-tree for this instead is cleaner, faster, and better. We do this by "cherry-picking" the old branch with git merge-tree, but providing -X ours as the strategy. This provides a tree that looks like the new base with the old changes applied. For cases where the old changes don't apply cleanly, the ours strategy prevents conflicts by taking the version in the old tree. Although this can be a bit confusing when looking at the file as a whole, it provides a succinct way to view a difference between the old version and new version. Topic: mergetreepatch Fixes: #183
jerry-skydio
added a commit
that referenced
this issue
Jul 3, 2024
Previously patchsets used a hacky invocation of update-index to overlay changed files from old tree to new tree. In addition to being slower than necessary, this has the downside of showing upstream changes in the diff, even those that were not changed in the given review upload. Using git merge-tree for this instead is cleaner, faster, and better. We do this by "cherry-picking" the old branch with git merge-tree, but providing -X ours as the strategy. This provides a tree that looks like the new base with the old changes applied. For cases where the old changes don't apply cleanly, the ours strategy prevents conflicts by taking the version in the old tree. Although this can be a bit confusing when looking at the file as a whole, it provides a succinct way to view a difference between the old version and new version. Topic: mergetreepatch Fixes: #183 Relative: gitconfig
jerry-skydio
added a commit
that referenced
this issue
Jul 3, 2024
Previously patchsets used a hacky invocation of update-index to overlay changed files from old tree to new tree. In addition to being slower than necessary, this has the downside of showing upstream changes in the diff, even those that were not changed in the given review upload. Using git merge-tree for this instead is cleaner, faster, and better. We do this by "cherry-picking" the old branch with git merge-tree, but providing -X ours as the strategy. This provides a tree that looks like the new base with the old changes applied. For cases where the old changes don't apply cleanly, the ours strategy prevents conflicts by taking the version in the old tree. Although this can be a bit confusing when looking at the file as a whole, it provides a succinct way to view a difference between the old version and new version. Topic: mergetreepatch Fixes: #183 Relative: gitconfig
jerry-skydio
added a commit
that referenced
this issue
Jul 8, 2024
Previously patchsets used a hacky invocation of update-index to overlay changed files from old tree to new tree. In addition to being slower than necessary, this has the downside of showing upstream changes in the diff, even those that were not changed in the given review upload. Using git merge-tree for this instead is cleaner, faster, and better. We do this by "cherry-picking" the old branch with git merge-tree, but providing -X ours as the strategy. This provides a tree that looks like the new base with the old changes applied. For cases where the old changes don't apply cleanly, the ours strategy prevents conflicts by taking the version in the old tree. Although this can be a bit confusing when looking at the file as a whole, it provides a succinct way to view a difference between the old version and new version. Fixes: #183
jerry-skydio
added a commit
that referenced
this issue
Sep 4, 2024
Previously patchsets used a hacky invocation of update-index to overlay changed files from old tree to new tree. In addition to being slower than necessary, this has the downside of showing upstream changes in the diff, even those that were not changed in the given review upload. Using git merge-tree for this instead is cleaner, faster, and better. We do this by "cherry-picking" the old branch with git merge-tree, but providing -X ours as the strategy. This provides a tree that looks like the new base with the old changes applied. For cases where the old changes don't apply cleanly, the ours strategy prevents conflicts by taking the version in the old tree. Although this can be a bit confusing when looking at the file as a whole, it provides a succinct way to view a difference between the old version and new version. Fixes: #183
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To generate the virtual diff target, squash the old PR into one commit (headoid, parentoid of last commit). Use merge-tree to merge this into
current base. Use -X theirs to prefer the old PR's versions when applicable.
Cases
Old pr conflicts with latest base -- diff will look like it went from old PR-like text to new pr. may be confusing?
Old pr deletes file that base changed -- diff will look like file either remains deleted, or was created
Base deleted file that old pr changed -- diff will look like file is there then got deleted
The text was updated successfully, but these errors were encountered: