Fix applying custom patches to a dirty working tree #4674
Merged
+271
−16
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
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferencesFootnotes
|
Curiously, the function was never called so far, but we're going to use it later in this branch.
This is functionality that works already, we only add the test for more complete test coverage. However, there's a detail problem, and the test demonstrates this: we keep the stash even if there was no conflict. We'll fix this next.
The tests show that this currently fails with the confusing error message "does not match index", regardless of whether the patch conflicts with the modifications or not. We'll improve this in the next commit. I don't bother adding tests for reverting a patch, as the code is basically the same as for apply.
Unlike moving a patch to the index, applying or reverting a patch didn't
auto-stash, which means that applying a patch when there's a modified (but
unstaged) file in the working tree would error out with the message "error:
file1: does not match index", regardless of whether those modifications conflict
with the patch or not.
To fix this, we *could* add auto-stashing like we do for the "move patch to
index" command. However, in this case we rather simply stage the affected files
(after asking for confirmation). This has a few advantages:
- it only changes the staging state of those files that are contained in the
patch (whereas auto-stashing always changes all files to unstaged)
- it doesn't unnecessarily show a confirmation if none of the modified files are
affected by the patch
- if the patch conflicts with the modified files, the conflicts were "backwards"
("ours" was the patch, "theirs" the modified file); it is more logical if "ours"
is the current state of the file, and "theirs" is the patch.
It's a little unfortunate that the behavior isn't exactly the same as for "move
patch to index", but for that one we do need the auto-stash because of the
rebase that runs behind the scenes.
stefanhaller
force-pushed
the
fix-applying-patches-to-dirty-working-copy
branch
from
068daaa to
3df894e
Compare
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.
Applying or reverting a custom patch when one of the files contained in the patch had unstaged modifications in the working tree would fail with the confusing error message "does not match index", regardless of whether those modifications conflicted with the patch or not. You would expect this to just work if there are no conflicts, or to get the usual conflict markers if there are. It was possible to work around this by manually staging those files, but few people knew about this. Fix this by staging the files (after asking for confirmation).
Also, fix a minor problem where an auto-stash for the "move patch to index" command was forgotten to be dropped.