Matthias Beyer <mail@xxxxxxxxxxxxxxxx> writes:
> I just experienced a `git cherry-pick <commit> --no-rerere-autoupdate` where the
> conflict still got automatically resolved from rerere.
If I am not mistaken, this is totally expected. You told the
command "use rerere but do not blindly accept the replayed
resolution into the index".
When you run "cherry-pick" there are three possible outcomes:
* The change <commit> wanted to make cleanly replays on top of
HEAD. Unless --no-commit is given, we update the index and the
working tree, make a commit, and advance HEAD to point at the new
commit.
* The change does not cleanly replay, and you either do not have an
earlier resolution recorded in the rerere database, or you tell
rerere not to kick in by setting the rerere.enabled configuration
variable to 'false'. In this case, the working tree files would
have conflict markers in them and the index would have higher
stages for these conflicted paths to record the original, our,
and their versions.
* The change does not cleanly replay, but your rerere database
knows a resolution you accepted already that applies cleanly, and
you allow rerere to kick in by the rerere.enabled configuration
variable. This will update the working tree files by replaying
the recorded resolution, but leaves the index conflicted, so that
you can inspect the auto-resolution with "git diff --cc".
If rerere is allowed to update the index with the result of its
operation (either by the rerere.autoupdate configuration or the
--rerere-autoupdate command line option), it also adds the result
to the index ("git diff --cc" would no longer work as a way to
view how the conflict was resolved).
I think the default these days is to allow rerere to replay the
resolution to the working tree files, but not allow the index to be
auto-updated. This allows people to be lazy but still be careful
before (re)committing to accept the previous resolution to the
index.
The above is not limited to "git cherry-pick", but applies also to
any mergy operation like "git merge", "git revert", and "git am -3".
A bonus protip. Always write dashed options to a subcommand (like
"cherry-pick") before non-option argument, i.e.
git cherry-pick --[no-]rerere-autoupdate <commit>
Some subcommands may be lenient and take arguments given in a wrong
order when they are not ambiguous, but it is a good discipline to
follow.
