Here's the deal. master has a file, file1. I branch, and delete that file in the branch. Meanwhile, I modify file1 on master. Boom, conflict.
When I merge my branch into master, the resolution is to delete the file. I'm trying to use git rerere
to be able to do the same resolution multiple times, but as you can see below it doesn't record the resolution in the case when you're deleting the file.
I can't find any docs on this specifically, is this just a limitation of rerere
?
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✓| → touch file1.txt
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✗| → git add . && git commit -m 'File1'
[master (root-commit) 95a807e] File1
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file1.txt
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✓| → git checkout -b delete_file_1
Switched to a new branch 'delete_file_1'
|system| brad-macbook-air in ~/tmp
± bb+ih |delete_file_1 ✓| → git rm file1.txt
rm 'file1.txt'
|system| brad-macbook-air in ~/tmp
± bb+ih |delete_file_1 ✗| → git commit -m 'rm file1'
[delete_file_1 83d1a57] rm file1
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 file1.txt
|system| brad-macbook-air in ~/tmp
± bb+ih |delete_file_1 ✓| → git checkout master
Switched to branch 'master'
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✓| → echo 'hello' > file1.txt
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✗| → git commit -am 'update file1'
[master 16f6541] update file1
1 file changed, 1 insertion(+)
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✓| → git merge delete_file_1
CONFLICT (modify/delete): file1.txt deleted in delete_file_1 and modified in HEAD. Version HEAD of file1.txt left in tree.
Automatic merge failed; fix conflicts and then commit the result.
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✗| → git rm file1.txt
file1.txt: needs merge
rm 'file1.txt'
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✗| → git commit --no-edit
[master 4791204] Merge branch 'delete_file_1'
Here we should see something like "recorded resolution for file1.txt", but we don't. Just to be sure it's not recording our resolution, we keep going and do the exact same merge again:
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✓| → git reset head^
Unstaged changes after reset:
D file1.txt
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✗| → git co .
|system| brad-macbook-air in ~/tmp
± bb+ih |master ✓| → git merge delete_file_1
CONFLICT (modify/delete): file1.txt deleted in delete_file_1 and modified in HEAD. Version HEAD of file1.txt left in tree.
Automatic merge failed; fix conflicts and then commit the result.
And here you can see that git rerere
doesn't remember the conflict resolution (and in fact incorrectly leaves the file in the tree).
The git rerere functionality is a bit of a hidden feature. The name stands for “reuse recorded resolution” and, as the name implies, it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can resolve it for you automatically.
Luckily, Git offers powerful tools to help navigate and resolve conflicts. Git can handle most merges on its own with automatic merging features. A conflict arises when two separate branches have made edits to the same line in a file, or when a file has been deleted in one branch but edited in the other.
As the way it stands right now, No. rerere tries to record previous resolutions based on hunks in each conflicted file. In case of delete, rerere sees it only as no hunks to resolve.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With