Re: cherry-pick with --no-rerere-autoupdate does still rerere?

[Junio C Hamano <gitster@pobox.com>]

Matthias Beyer <mail@beyermatthias.de> 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.