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

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

[Matthias Beyer]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

Hi,

I just experienced a `git cherry-pick <commit> --no-rerere-autoupdate` where the
conflict still got automatically resolved from rerere.

Is this a known bug, or am I doing something wrong?

    $ git cherry-pick 61c16c9 --no-rerere-autoupdate
    Auto-merging crates/common/tedge_utils/src/file.rs
    CONFLICT (content): Merge conflict in crates/common/tedge_utils/src/file.rs
    error: could not apply 61c16c9cd... Fix (style): Do not use dedicated statement for return value
    hint: After resolving the conflicts, mark them with
    hint: "git add/rm <pathspec>", then run
    hint: "git cherry-pick --continue".
    hint: You can instead skip this commit with "git cherry-pick --skip".
    hint: To abort and get back to the state before "git cherry-pick",
    hint: run "git cherry-pick --abort".
    Resolved 'crates/common/tedge_utils/src/file.rs' using previous resolution.

Using

    $ git --version
    git version 2.36.0

Best,
Matthias

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Junio C Hamano]

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.

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

[Matthias Beyer]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

Excerpts from Junio C Hamano's message of Juli 2, 2022 9:04 pm:
> 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".

Ah! After over 10 years of using git, I still missed that ("update the index" in
the manpage). I was thinking about "cherry pick this, but don't use rerere at
all".

Thanks for clearing up my confusion!
Matthias


-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Junio C Hamano]

Matthias Beyer <mail@beyermatthias.de> writes:

> Excerpts from Junio C Hamano's message of Juli 2, 2022 9:04 pm:
>> 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".
>
> Ah! After over 10 years of using git, I still missed that ("update the index" in
> the manpage). I was thinking about "cherry pick this, but don't use rerere at
> all".
>
> Thanks for clearing up my confusion!

It is highly appreciated that you gave us an opportunity to
improving the documentation (or possibly something else) to avoid
getting other users into a similar misunderstanding.

A discussion, proposal, or a patch to improve docs and helps is
certainly welcome.

[PATCH] Add note that conflict resolution is still performed

[Matthias Beyer]

We should note that conflict resolution is still performed, even if
`--no-rerere-autoupdate` is specified, to make sure users do not get
confused by the setting and assume this disables rerere conflict
resultion all together.

CC: Phillip Wood <phillip.wood@dunelm.org.uk>
CC: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
---
 Documentation/git-cherry-pick.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 78dcc9171f..730a4590af 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -160,6 +160,8 @@ effect to your index in a row.
 --no-rerere-autoupdate::
 	Allow the rerere mechanism to update the index with the
 	result of auto-conflict resolution if possible.
+	If `--no-rerere-autoupdate` is specified, the conflict resolution is
+	still performed, but the index is not updated.
 
 SEQUENCER SUBCOMMANDS
 ---------------------
-- 
2.36.0