Small rerere in rebase regression

Even though I operate with jc/rerere-multi for some time now, I noticed this regression only recently. Watch out for the duplicated "Recorded preimage" message:

gittest@side:1078> strace -f -o /tmp/git-rebase-conflict.strace git rebase -i master error: could not apply 59f92e0... side

When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort".

Recorded preimage for 'a' Recorded preimage for 'a' Could not apply 59f92e09c890c08442eb1df91eaecec3d1656c86... side

According to the strace, the first "Recorded preimage" is from git cherry-pick, the second is from "git rerere" in this section in git-rebase--interactive.sh:

die_with_patch () {
	echo "$1" > "$state_dir"/stopped-sha
	make_patch "$1"
	git rerere
	die "$2"
}

The buglet bisects to

629716d256a792179325c2cc7945bb2d81dda8c2 is the first bad commit
commit 629716d256a792179325c2cc7945bb2d81dda8c2
Author: Junio C Hamano <gitster@pobox.com>
Date:   Thu Jul 30 15:49:18 2015 -0700

    rerere: do use multiple variants
    
    This enables the multiple-variant support for real.  Multiple
    conflicts of the same shape can have differences in contexts where
    they appear, interfering the replaying of recorded resolution of one
    conflict to another, and in such a case, their resolutions are
    recorded as different variants under the same conflict ID.
    
    We still need to adjust garbage collection codepaths for this
    change, but the basic "replay" functionality is functional with
    this change.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

I'm not sure whether the new behavior is a defect in rerere.c or a consequence of the extra rerere call in interactive rebase...

-- Hannes