I'm using git rerere, and it is useful, but there is one problem: When it automatically resolves a file, it does not mark it as resolved (eg with git add). So if I run 'git mergetool', it opens up the file as if it still has all the conflicts in it.
So far, I've made a small shell script which I can call, which scans all files marked as conflicted for conflict markers (eg >>>>>>>
), and calls git-add on them if they have none.
Is there a better way of doing this? Some f开发者_运维问答lag to git rerere I missed?
Maybe a git config
setting can help:
rerere.autoupdate
When set to true,
git-rerere
updates the index with the resulting contents after it cleanly resolves conflicts using previously recorded resolution.
Defaults to false.
Note: since Git1.7.0,
"
git rerere
" hadrerere.autoupdate
configuration but there was no way to countermand it from the command line;
--no-rerere-autoupdate
option given to "merge
", "revert
", etc. fixes this.
Git 2.38 (Q3 2022) updates documentation on the "--[no-]rerere-autoupdate
" option.
See commit cb54fc9 (03 Aug 2022), and commit 0dbc715 (15 Jul 2022) by Junio C Hamano (gitster
).
(Merged by Junio C Hamano -- gitster
-- in commit 3adacc2, 14 Aug 2022)
doc
: clarify rerere-autoupdate
The "
--[no-]rerere-autoupdate
" option controls what happens after the rerere mechanism kicks in to reuse recorded resolutions and does not prevent from the rerere mechanism to trigger in the first place.It is unclear in the current text if "
--no-rerere-autoupdate
" stops the auto-resolution.
Rewrite the sentence to clarify.
rerere-options
now includes in its man page:
After the rerere mechanism reuses a recorded resolution on the current conflict to update the files in the working tree, allow it to also update the index with the result of resolution.
--no-rerere-autoupdate
is a good way to double-check whatrerere
did and catch potential mismerges, before committing the result to the index with a separategit add
.
精彩评论