From: Jay Soffian <jaysoffian@gmail.com>
Date: Tue, 15 Jun 2010 13:08:57 GMT
Subject: Re: Amending a merge commit doesn't update the rerere cache
Message-ID: <AANLkTimlVyDCc72yirAcL0t0YEWErAT_e0Fadq-WbxNM@mail.gmail.com>
In-Reply-To: <4C171C7B.3060904@viscovery.net>

On Tue, Jun 15, 2010 at 2:23 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> There is
>
>        git rerere forget that/conflicted/file
>
> It definitely works as long as the conflict is still recorded in the
> index; I'm not sure if it works after you have staged the updated resolution.

In fact, I use "rerere forget" as part of a hacked up rerere-train
that I call after I've gotten my merge correct:

---- snip ----
set -- $(git rev-list --parents HEAD -1)
commit=$1; shift
parent1=$1; shift
other_parents="$@"
if test -z "$other_parents"; then
        echo >&2 "HEAD is not a merge commit"
        exit 1
fi

whence=$(git rev-parse --abbrev-ref HEAD)
trap 'git checkout "$whence"' EXIT

git checkout -q "$parent1^0"
if git merge $other_parents; then
        echo "HEAD merges cleanly"
        exit 0
fi

git show -s --pretty=format:"Learning from %h: %s" "$commit"
git rerere forget 2>/dev/null
git checkout -q $commit -- .
git rerere
---- snip ----

I'm still interesting in making commit do the right thing though. In
general, rerere is an underdocumented feature; I guess I'll start
fixing that part first.

(Aside: and the reason I care about rerere being correct is that I
often need to eventually rebase these merges, which is itself a rather
delicate procedure.)

j.